[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Graphic flicker in GNUStep
Re: Graphic flicker in GNUStep
Fri, 01 Dec 2006 18:26:12 +0700
Thunderbird 18.104.22.168 (X11/20060921)
David Espada wrote:
This is the first time I write here. Excuse my poor english, I am not
I have been probing GNUStep in Debian Linux Testing (Etch). I can't
decide about quality because of two reasons:
- Applications seems to be very pedestrian, except development
applications, like Gorm, ProjectCenter... But that is a known
issue and I don't like raise it again.
- I feel an extrange flicker in graphics that doesn't exist in
other graphic toolkits (like Gtk or Qt). I thougt that GNUStep
was lightweight soft, but when you resize a window or change
virtual desktop, it seems to flicker excesively, as if it
weight too much.
I think these are known issues. I don't have a certain idea of how to
solve these problems. Though, I have some opinions.
First I remind you, GNUstep's drawing is slow comparing with the other
systems because it relies
on PostScript like display engine which is slower than the others'
but that's a trade-off with WYSIWYG. (GTK+ uses cairo too, though we are
pretty more upto it
than GTK+, since GNUstep allow you to do much more advance things than
GTK+'s API do)
And so that lead to another problem that when resizing window, since
that trigger a
few intensive drawings. One way around this is by compressing X11's
notify event so drawings were not requested at every bit of resizing.
This was addressed
long time ago, but it was not interesting enough so nobody fix that
they are using Window Maker that doesn't allow the kind of windows resizing.
If you are interested, you can fix that yourself by fixing
around ConfigureNotify. The same kind of compression was done for
by someone who never use such apps that need more granular mouse
tracking eg. gimp ;)
(This issue was also addressed, long time ago, but again it was also not
interesting enough to get fixed)
Another way is by using xdbe (x11 double buffering extension)
but that would waste more memory. That wouldn't make drawing faster, just
updating in a smoother manner _and_ that isn't solving the window
but may solve a synchronizing problem that happen on every mode I tried
to create an NSWindow which cause flickering when drawing intensively.
Another idea is to allow "full stop operation" and split the drawing
a different thread which stacks drawing operations from the client and can
discard some operation not neccessary. So the drawing code/app can tell
the drawing backend using the full stop op that an ROI will be completely
covered by some following ops. I also expected this model to very work
a server/client over IPC.
BTW, In near future, the drawing method can be highly accelerated by using
GPU, for example, if our cairo glitz backend actually work.
Is there a known reason for the second point? Is is very annoying and
gives GNUStep an amateurish feeling.
Thanks for your hard work.
Discuss-gnustep mailing list
- Re: Graphic flicker in GNUStep,
Banlu Kemiyatorn <=