<br><br><div class="gmail_quote">On Sun, Mar 8, 2009 at 10:33 AM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@kokkinizita.net">fons@kokkinizita.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class="im"><br>
> the problem is that its not always "your" display code that is the problem.<br>
> we reworked the canvas display logic to avoid a very nasty problem with X &<br>
> the GnomeCanvas. the Canvas has no concept of "zoom, keeping the center of<br>
> the current display in the center".<br>
<br>
</div>You mean it has no call to set the offset and scale<br>
(mapping between user coordinates and pixels) in one<br>
call ? Or it has but translates this into two separate<br>
operations ? That is a serious defect.</blockquote><div><br>it no call to set scale & offset, and even if it did, its scrolling model would split it in two.<br><br>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.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> because X is async, you can sometimes (often!) see the intermediate state<br>
> between the window move and the redraw.<br>
<br>
</div>That's not because X i async, just because there is<br>
an intermediate state, and it takes finite time to<br>
repaint. </blockquote><div><br>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.<br>
<br>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. <br>
<br><br></div></div><br>