Hi Thomas,
Comments inline. From: [email protected] [mailto:[email protected]] Sent: Saturday, 13 December 2008 00:16 To: [email protected] Cc: [email protected] Subject: RE: FW: Some anomalies using overlapping SVG canvasses Hi John, "John C. Turnbull" <[email protected]> wrote on 12/12/2008 06:58:41 AM: > Thank you for taking the time to reply to my difficult questions. > > > My guess is that you see the old top canvas contents until the > > top canvas can complete it's rendering? I guess my question is > > what do you want to have happen? Do you want all repaints to > > block until the top canvas rendering is complete? > > No, I only want any rendered content of other lower objects that would > normally be behind the top canvas to always be behind, even when the top > canvas is "busy". I am not sure what I am requesting is possible but I am > sure that it is desirable. It's not possible. You bascially have two options. 1) Block all repaint requests until all canvas's are in sync. Which means that the background animation will stop while the foreground canvas updates it's self. 2) Accept some sort of 'proxy' for the updated content. It seems that you are potentially happy with proxies that can be provided for zoom in/out pan, but you aren't happy with the proxies that can be provided for dragging. It might be possible to convince the canvas to do #1 for 'updates' (document modifications) and #2 for re-render requests (viewing transform changes). To be honest I think this is likely to be very difficult to behave well. But if I were going to do it. I would add a monitor object to the canvas (probably a simple Bool object) that indicates if the offscreen buffer is 'clean' (true) or 'dirty' (false). In the paintComponent' method I would synchronize on the object and then check if it's true if so painting would continue normally. otherwise I would 'block' (which is tricky since we sometimes need to access the AWT event thread during document updates) until the update completes (and the monitor is set true). You would set the monitor to false in response to 'updateStarted' event callbacks, and clear the monitor in 'updateCompleted' event callbacks. Did I mention that I think that this would be difficult. It would be much simpler to simply draw everything in one canvas.... [JCT] It is indeed simpler in one canvas but there are also limitations which I am trying to overcome namely the inability to run multiple JavaScript-based animations simultaneously and also that performance degrades significantly the more you pack into one SVG/canvas. > > When you translate with the left and right arrow keys we update > > the 'painting transform' so that the un-updated offscreen buffer > > is correctly positioned, but you will notice that there is 'blank > > space' where that buffer has moved away from the edge of the window. > > You may not be aware that if you use 'shift mouse-2' we will scale > > in a similar manner, and 'ctrl mouse-2' will rotate with painting > > transform update. > > These seem to work perfectly! Why can't everything be like this? Because we don't have as good a proxy for most cases. BTW did you try zooming out? Was it acceptable that during the repaint areas that were uncovered were 'transparent' in the top canvas until the repaint completed? [JCT] Yes I tried zooming out and, to be honest, I don't notice these blank areas. I can zoom in and zoom out amazingly quickly and never does the back animation interfere with the rendering of the top canvas's objects. I see though that this is not a true SVG zoom but a buffered image zoom instead. I still don't understand why true zooming cannot be like this too (sorry if I am a bit slow on the uptake). > >> So why can't the top object paint itself while it is being resized > >> or dragged? Is something else going on? > > > > It can't paint itself with the updated rendering because > > it's busy making that updated rendering. So the question is what > > do you want to have happen while it's making that updated rendering? > > As my knowledge of the intimate inner workings of the rendering engine is > incomplete, I can only tell you what I would like to see from the user's > perspective. Objects which are rendered in canvasses behind those rendered > in "higher level" (closer to the top) canvasses should *always* be behind > those on the top. Until the top object is done drawing I can't draw the top object. The problem you are seeing is because it takes time to draw that top object. Effectively what you are saying is that you don't want the drawing of the top object to take any time - which of course is what every user wants, but also is impossible. So you will need to figure out something that makes you happy that isn't impossible, or else find a way to be happy about being unhappy ;) [JCT] Actually, what I want is not necessarily for the top object to render instantaneously but rather that it always renders when required using either the "before" state or "after" state when that has been calculated. At the moment it looks like a request is being made to re-render the top object but it is not doing so because it is busy calculating the scaled version or drawing it to the off-screen buffer. What I'd like to see is that when that request is made the top object renders with the "before" state while it's busy and then the "after" state when it's ready. That way the underlying animation will not show through at any stage. I had tried to achieve this by modifying the code. I figured that if the paintComponent method simply paints the off-screen buffer then if it's busy doing something else it would still paint with the "before" image providing the buffer has not been set to null which happens in a few places in the code. I tried removing the null setting (realising that this may expose memory leaks) but the result was the same. Does this make any sense? Can it be done? > There should be no battle to display themselves, the top > objects should be declared the winner always. So when I request a resize, > no lower objects should show through the top object either before, during or > after the top object's resize (unless of course it is translucent!). The > same applies when I drag the top object. Basically, the Z-order of all > objects should be honoured at all times. Is this possible? [JCT] Thanks, John.
PGP.sig
Description: PGP signature
