The problem with this is that, the Java
editor is owned by JDT, whereas the GC.drawText call is in SWT. I could
see the Java editor knowing that "if", "while", etc.
are interesting, but it doesn't make sense to me for the generic text drawing
routine to do this. In any case, the real issue with the strategy is that
feels like it is optimizing for something that should just be fixed in
the platform API. I recognize that SWT's use of Pango is atypical, but
we can't be the only app that wants to control things at this level(?).
McQ.
Steen Jansdal <steen@xxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
15/12/03 09:40
Please respond to
platform-swt-dev
To
platform-swt-dev@xxxxxxxxxxx
cc
Subject
Re: [platform-swt-dev] swt
on gtk slow
Bradley Schatz wrote:
> Any suggestions on how to get eclipse running as snappily as it does
on
> windows when running swt/gtk?
>
> thanks
>
>
Suggestion for the SWT developers:
The editor under GTK is painfully slow and I suspect
pango is to blame for this. When drawing the editor
a lot of slow GC.drawText calls are made. Each time
a GC.drawText call are made pango has to do a slow
relayout calculation because SWT is using the same
pango layout for all GC.drawText calls. Perhaps it
would be faster to implement some kind of cache of
layouts.
For example when displaying a typical java source
file, it contains a lot of "if"'s, "while"'s, "int"'s,
equal-signs, parentheses,...
If it were possible to get a previously calculated
pango-layout of the same text and font, the drawing
would theoretically be faster. But would it be faster
than the added maintenance of the cache?
What do you think about this approach?
Steen Jansdal
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev