On Sun, 27 Oct 2002 18:59:53 -0800 Allen Akin <[EMAIL PROTECTED]> babbled:
> Or perhaps it's the apps, rather than the toolkits, that are causing the
> problem? But if so, they still seem to be using a lot more time than I
> would have expected. Maybe it's mostly the lack of synchronized
> double-buffering that causes the visible glitches?
i know it's a combination of:
1. lack of experience and good grounding in graphics
2. lack of knowlegde of x and in general doing things that take worst-case
routes to perform rather than best-case,
3. somewhat in toolkit design, somewhat in toolkit implementation
4. some in application implementation and somewhat in design.
now i do know toolkits with heave window use (in fact any child window use at
all starts off he cycle) breeds a self feeding multiple-redraw loop.
eg:
window resizes. viewport is child. on a resize the viewport is moved and resized
too. the contents of the viewport need a redraw
the window that is the parent needs a redraw to redraw bevels and surroundings.
on a resize the redraw happens and the window gets moved and resized and
redrawn. now the window move and resize will have cause exposes. this goes on a
server round trip and back again causing more redraws needed of what was just
drawn. this gets nice and friendly too when we involve shaped windows. :)
often apps don't wait till idle time (all input events have been processed and
app/toolkit state has stabilized to update the ui), but do it immediately. it's
easier to do immediately if you are new to gfx, but much less efficient than
deferring update till idle.
to be honest the vsync double buffer isn't much of an issue. the problem is the
apps end up re-processing what to do and then doing it multiple times instead of
just once. the other issue is a lot of toolkits and apps still use pixmaps and
masks (which have to be scanned and broken into rect lists) and this ends up a
lot of extra work - especially if it's done multiple times. they often do it all
with the cpu as they cant be guaranteed of being able to do the effects they
want with X itself so they have a fallback they just end up using all the time.
this is just a matter of time as everyone uses new apis that work and are fast
(render, opengl) instead.
so really the problem is more 1. having fully accelerated paths that you can
depend on. 2. better programming to account for self-feeding event loops (the
move window and expose result as described above). personally i have become fond
of the zero child windows method of doing an app myself :)
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
[EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
