Re: Graphic flicker in GNUStep

[Banlu Kemiyatorn]

David Espada wrote:
>  Hello, group.
>
>  This is the first time I write here. Excuse my poor english, I am not
>  native speaker.
>
>  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' 
drawing method
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 
configure
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 
probably because
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 
XGServerEvent.m, somewhere
around ConfigureNotify. The same kind of compression was done for 
MotionNotify
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 
resizing issue
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 
code into
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 
well as
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.
>
>                                                         David
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>