[Ardour-Dev] SuperRapidScreenUpdates are neither rapid, nor super.

[Paul Davis]

On Sun, Mar 8, 2009 at 10:33 AM, Fons Adriaensen <fons at kokkinizita.net>wrote:

>
>
> > the problem is that its not always "your" display code that is the
> problem.
> > we reworked the canvas display logic to avoid a very nasty problem with X
> &
> > the GnomeCanvas. the Canvas has no concept of "zoom, keeping the center
> of
> > the current display in the center".
>
> You mean it has no call to set the offset and scale
> (mapping between user coordinates and pixels) in one
> call ? Or it has but translates this into two separate
> operations ? That is a serious defect.


it no call to set scale & offset, and even if it did, its scrolling model
would split it in two.

that said, nick mainsbridge did come up a way (a rather obvious way, in
retrospect) for us to use the canvas and make this work. but it involved
ceasing all use of the canvas's own scrolling/zoom mechanism, and setting up
redraws in our own code. this is not a huge issue, and has many benefits,
but i strongly suspect that it will have broken the "stationary playhead"
hack that john was using.


>
>
> > because X is async, you can sometimes (often!) see the intermediate state
> > between the window move and the redraw.
>
> That's not because X i async, just because there is
> an intermediate state, and it takes finite time to
> repaint.


well, the point is that will always handle two requests serially. if you
send XWindowMove request and then arrange for a redraw to be delivered via
X, there are two requests, and every chance that they will span a vertical
retrace (since X pays almost no attention to the vertical retrace, by
design). if both events are on the same "side" of a vertical retrace, you
don't see the intermediate state. alternatively (as we are now doing),
simply don't use two different X requests, and thus there is no intermediate
state. the redraw no longer uses any X machinery until its time to blit the
pixmap to the screen.

its been very interesting to do some very level work on the OS X port of
GTK. most people don't realize that OS X is using a client/server model for
graphics too (though its not network transparent, like X), and they really
learned a lot from the weaker parts of X. most of what Xorg is now doing
with X was designed into Aqua many years ago, and although the lack of
network transparency is a huge drawback from my perspective, i find it very
instructive to see how their drawing model differs from X and the ways in
which they have (generally) managed to provide a much nicer environment for
application authors in this respect. X is getting better (quite dramatically
in some areas), but its just not as cohesive when thinking about modern
hardware and modern drawing styles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20090308/b9195e7c/attachment-0002.htm>