<AWT Dev> Question about GtkLnF implementation

[Damjan Jovanovic]

Hi Anthony, Clemens, others

There's an interesting comment, quoted below, in the evaluation of
http://bugs.sun.com/view_bug.do?bug_id=6286734

---BEGIN QUOTE---
I have an idea of impoving overall GTK LAF performance by implementing
own gdk backend which would draw gtk widgets directly to
X11SurfaceData backing buffer.
It improves GTK LAF performance dramatically especially on remote
hosts (up to 20 times).
Together with some minor changes it would be a better solution for this "bug"
Uncommit it from Mustang becasue I'm getting late with this feature.
Posted Date : 2006-03-27 13:03:58.0
---END QUOTE---

Who wrote this (I suspect Kirill Kirichenko for some reason) and is
this code still around? It would really help to see it.

Thank you
Damjan


On Mon, Feb 1, 2010 at 5:19 PM, Anthony Petrov <Anthony.Petrov at sun.com> wrote:
> Hi Clemens, Damjan,
>
> [ also copying the swing-dev@ list ]
>
> AFAIK, there currently nobody working on such an enhancement to the Swing
> GTK L&F implementation. This L&F is by far not the fastest one out there, so
> any improvement is very welcome.
>
> If either of you could help with developing a fix, that would be very much
> appreciated.
>
> --
> best regards,
> Anthony
>
> On 1/30/2010 7:47 PM Clemens Eisserer wrote:
>>
>> Hi Damjan,
>>
>>> The number of roundtrips isn't such a problem, the number is pixels
>>> is. 2 NxM pixmaps have the same number of pixels in total as an Nx2M
>>> or 2NxM pixmap, so little time is saved.
>>
>> Sure the amount of data stays the same - however for (most modern)
>> video drivers which place their pixmaps in vram it does make a
>> difference.The whole situation is quite ugly :-/
>>
>>> Anyway, when last I heard the solution to this was to subclass GDK
>>> drawing functions so they draw with the alpha channel in the first
>>> place, instead of the double drawing without alpha and then mixing
>>> pixmaps to recover it. Anyone working on this?
>>
>> Hmm, I guess the best thing would be to get GTK's broken theme API
>> right, to draw on a cairo-context instead of a GdkDrawalbe.
>>
>> I submited patches for rfc some time ago, but nobody really looked at
>> it. To me it seems GTK is quite dead.
>> When I brought that topic up again, it was mentioned that the work is
>> obsolete because GTK+3 will have an all new-any-shiny theming API
>> which will be perfect in any aspect.
>>
>> However they are talking about GTK+3 for about 2,5 years now, with no
>> outcome.
>>
>> Hmm, I am starting to get personal again ;)
>>
>> - Clemens
>