Switching to functional is the current trend I guess. Now you can argue whether or not it's smart to change design approach because it's a trend. As a framework - probably yes as you get higher adoption rates. As an application developer probably not - as it just creates extra maintenance for when the next trend comes around.
On Sun, Feb 9, 2025 at 12:30 AM Craig Mitchell <[email protected]> wrote: > > *OO vs procedural/functional is quite the different design approach. I > would even say that those are worlds apart.* > > Tell that to the React creators, that switched the framework from OO to > functional. 😝 > > On Sunday, 9 February 2025 at 8:49:40 am UTC+11 Leon wrote: > >> I can see where you say a developer familiar with the DOM is more likely >> to work with on the canvas api directly. >> And yes, the more technical options the better. Sure. >> But I do not see how you can say that an OO vs procedural or functional >> approach is not that relevant? OO vs procedural/functional is quite the >> different design approach. I would even say that those are worlds apart. In >> what way do you think that this difference not relevant? >> >> >> On Sat, Feb 8, 2025 at 8:53 PM Colin Alworth <[email protected]> >> wrote: >> >>> >>> @Craig - If you draw everything on the same canvas, the zoom/scale works >>> on everything on that canvas. it limits what you can do with that canvas. >>> If you want to scale or zoom everything, yes then it doesn't matter. So yes >>> you are right, it depends on the project. >>> >>> This isn't true, it only applied on the operations that take place while >>> it is set. You can call scale(1, 1) to go back to 1:1, or you can use the >>> save()/restore() that Craig mentioned. You can also clip to keep the zoomed >>> content within certain bounds. >>> >>> @Colin - With multiple layers I would also need multiple canvas's and >>> overlay them right? >>> >>> Correct - each would have its own frame buffer, and could be >>> cleared/drawn independently. >>> >>> >>> We wrote a single adapter widget that uses a single canvas. This adapter >>> widget knows what the zoom level is. Objects that are drawn on that widget >>> of a certain type get zoomed, whilst others of a different type do not. It >>> is super simple and easily explained to new devs. Everyone on the team can >>> add views or objects and the type determines how these are displayed. Even >>> devs without exact knowledge of how the canvas works can develop and >>> maintain objects to be displayed. >>> >>> I guess it's also a development style/preference thing. If you code the >>> view of the canvas in a single class or single method, the solution is >>> likely to have to rely more on the technological capabilities of the >>> canvas. Working with an adapter then does not really make a lot of sense. >>> If you have more of an OO style of development, you express more in >>> functional blocks. Then you have to rely less on the technical capabilities >>> as you can translate what needs to be done on the basis of what your >>> objects are before you hit the canvas. Then the zooming/scaling happens >>> in the object, not on the canvas so to speak. >>> So the required functionality of the canvas remains fairly basic. >>> >>> I don't make these suggestions lightly - if you are happy with how >>> canvas performs and the quality of the output, then you may well never need >>> them, but it can be fun to know they exist. >>> >>> I don't much care about OO vs FP styles for this - building an API >>> around these features should be straightforward within whatever paradigm >>> you prefer. For most projects we ended up with roughly two layers of >>> abstractions - the "shapes that get drawn on the screen via canvas >>> commands" abstraction (iterate through "shapes", respect their "z-index" or >>> other relative positioning, capture clicks and figure out which "shape" was >>> clicked on, redraw only changed "shapes" and those that intersect them, >>> etc), and the "business logic drives what shapes to draw" abstraction ("I >>> want a pie chart in the corner, compute slices based on data", "these >>> buttons over here control those axes", "Labeled items in the legend will >>> drive which stars/circles in the chart are highlighted when hovered"). It >>> feels natural to someone who is used to working with a DOM (esp SVG), and >>> can handle thousands of items without much trouble. >>> >>> Zoom can appear at either level here - multiple coord systems, or make >>> the "zoom" part of the "shape" API. You're totally correct that scaling >>> need not happen at the "canvas level" - while the MDN link I gave seems to >>> imply that, it really is just trying to make it easier for the developer to >>> not need to think about one more "layer" of ways that their data needs to >>> be transformed. From a certain perspective, you might want to just have a >>> transform matrix that you apply to each shape, and compose your >>> zoom-because-zoom-widget, translate-because-panning, rotate, etc operations >>> all at that level, and just apply the transform once when drawing (or even >>> apply to the coords before you call in to canvas). None of it matters as >>> long as the math is correct. >>> >>> If you need more power, odds are you can find pretty quickly where the >>> "unnecessary" O(n^2) or O(n lg n) operations are taking place (sorted >>> insertion by z-index, solving for intersections, etc), and can do a better >>> job partitioning "shapes" or go all out and drop down to just "business >>> logic drives canvas commands" where it is required. >>> >>> >>> >>> performance wise, I've done fully animated person relation networks and >>> animated dashboards in large canvases for nearly a decade now. >>> We've never ran into any performance issues. >>> That being said, I think the views and on-screen actions we used were >>> somewhat limited when compared to developing a game with full world >>> rendering or something similar. >>> >>> Did I already say I love this gwt group? It makes me think a lot more >>> about what I am doing and why I am doing it. >>> Plus the input from the GWT devs usually give me insights I haven't >>> thought about before or didn't know existed. >>> >>> If you can stand the stream of discussion, you may also enjoy >>> https://matrix.to/#/#gwtproject_gwt:gitter.im. It tends to be more >>> conversational, and can get into the weeds in unrelated topics like this. >>> >>> >>> On Sat, Feb 8, 2025 at 2:56 AM Colin Alworth <[email protected]> >>> wrote: >>> >>> 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 a topic in the >>> Google Groups "GWT Users" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, 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 >>> <https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "GWT Users" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com >>> <https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "GWT Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CABjQu7SHp-%3DZV7O45xK0S2RpbXrM0A9EdWcy3seovy68wEEZdQ%40mail.gmail.com.
