I'm sorry if my message confused the two kinds of 'zoom' being discussed here - there's the one where the pixels on the physical monitor don't match the pixels of your display (this covers both HDPI and ctrl +/-), and there's the one where the user clicks the + icon (drawn on the canvas) to make everything inside a specific rectangle bigger.
The context2d.scale() method can do both, but I was mostly referring to the first, adapting to the user's current monitor+settings at any given time. Note that in this context, scale() does _not_ make things blurry when you zoom, but effectively multiplies all your coordinates by the scale. The canvas "height" and "width" (the "actual size" in the link's code sample) are what makes things blurry or super precise. In the second case, scale() can still be totally appropriate, especially if coupled with a "panning" feature, or if data is updating. Odds are very high that in those cases, the parts of the canvas outside the "rectangle" aren't moving - all the various controls, the rectangle itself. Avoiding redrawing whatever you can each frame is important for performance. Or, you can just adjust your coordinate system when projecting on to the canvas, multiplying by your current zoom factor for each position - as above, it is doing the same thing. While we're discussing it, clipping (with save/restore or without) still also be helpful to conserve rewrites too - if you had a single canvas element, you would clip to inside the rectangle, clear, and redraw only what is in there - save() and restore() are a valid way of handling that, or just reapply state at each pass. If you're careful, you could even just redraw a subset of the rectangle's contents - solve for which items actually changed (doing some intersection math), and clip+clearRect just that section, then redraw just what is in there. If you "draw" a little outside the clip in any of these cases, no big deal - it will get clipped out (but you'll still pay for the code to run, it just won't have any overdraw). If you think about this like "partitioning" the drawing area with clip, there are two other ways to partition too - you can "tile" canvases, selectively redrawing their entire contents if they are affected, and you can "layer" them, using transparency to enable lower layers or higher layers to remain intact when other layers need to be cleared and repainted. Tiling can also work with non-homogenous blocks - the "rectangle" above could be one canvas, and the "controls" could be in their own. On Friday, February 7, 2025 at 5:11:41 PM UTC-6 [email protected] wrote: > > *I would not use the scale functionality as it applies to the whole > canvas. * > > Whatever works for your project is best, however, the scale only applies > when you set it. And you can always reset it. Eg: > > // Save the current state > context2d.save(); > > // Apply zoom > context2d.scale(xxx, xxx); > > // Draw zoomed stuff > ... > > // Reset the zoom > context2d.restore(); > > This also lets browsers use the GPU to render (although, I'm not actually > sure if the scaling is done on the CPU or the GPU). > > On Friday, 7 February 2025 at 5:02:17 pm UTC+11 Leon Pennings wrote: > >> I would not use the scale functionality as it applies to the whole >> canvas. >> I'd prefer to apply an adapter pattern for determining actual coordinates >> on the canvas. >> Then you can still have a toolbar, location display or slider for the >> zoom factor in it's normal proportions and just have the actual content you >> want to show in a different scale. >> >> Op donderdag 6 februari 2025 om 13:33:12 UTC+1 schreef Colin Alworth: >> >>> No problem - I wanted to be sure I didn't make a mistake, since I >>> haven't myself used canvas "in anger" in many years, and only loosely keep >>> track of resources and advice on it. >>> >>> SmartGWT's "Draw" examples make the API look very similar to the GXT >>> "draw" packages - it isn't really a raster API at all, but a vector API >>> that just happens to be built on top of a canvas implementation. >>> >>> My recollection is that for fewer than around 1k-10k drawn items, SVG is >>> faster and simpler to understand than canvas, and canvas's benefits only >>> start kicking in when the DOM gets too heavy to manipulate quickly each >>> frame. Looking briefly at the example page you shared a few weeks ago, if >>> you were interested in getting into the low level details of how to do the >>> drawing, your case perhaps could stand being remade in plain SVG - always >>> high resolution. The benefits may be mostly for your own understanding >>> rather than any real observed performance improvements from running the >>> page (that said: dropping SmartGWT would appear to drop almost 8mb of JS >>> out of your 9+mb page). >>> >>> On Wednesday, February 5, 2025 at 9:46:51 PM UTC-6 >>> [email protected] wrote: >>> >>>> > Neil, I'm not sure where I appeared to have said that. >>>> >>>> >>>> >>>> I am sorry, I did not intend to put words in your mouth. >>>> >>>> That was my understanding from your previous email stating >>>> that canvas is a raster format. I misinterpreted your statements. >>>> >>>> >>>> >>>> I apologize for that. >>>> >>>> >>>> >>>> Thank you, >>>> >>>> Neil >>>> >>>> >>>> >>>> -- >>>> >>>> Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com >>>> >>>> We offer 30 year loans on single family houses! >>>> >>> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com.
