I'm developing a web app using Flex. This app allows to draw forms in a Canvas (like MSPaint in Windows).
Now, I want a new feature on it: an infinite canvas. The user should be able to drag the main Canvas and this should be infinite in X and Y axis. Consecuently, this Canvas should be resized in real time.
Obviously, I don't want to create a Canvas of 1k x 1k pixels with zoom in an specific area to give the feeling of an infinite drawing area.
How could I achieve it? Any suggestions or ideas are welcome :)
EDIT:
I just read that Flash/Flex Flash/Air supports canvases up to 4056x4056 px, not infinite.
You might want to reconsider how you implement your infinite canvas - a single, ever growing canvas, is likely to cause performance issues.
Instead, consider breaking your canvas into virtual canvases of fixed size (I'd recommend much smaller than the max of 4056x4056), and then stitch them together at runtime, as the user pans around.
Related
I have already read
What is the difference between SVG and HTML5 Canvas?
&&
https://en.wikipedia.org/wiki/Canvas_element#Canvas_versus_Scalable_Vector_Graphics_.28SVG.29
So i am aware of the basic differences, but i was wondering if anyone had encountered any practical difference between the two within the context of ggvis and shiny apart from SVG inability to deal with NA's in the data
The short answer:
SVG would be easier for you, since selection and moving it around is already built in. SVG objects are DOM objects, so they have "click" handlers, etc.
DIVs are okay but clunky and have awful performance loading at large numbers.
Canvas has the best performance hands-down, but you have to implement all concepts of managed state (object selection, etc) yourself, or use a library.
The long answer:
HTML5 Canvas is simply a drawing surface for a bit-map. You set up to draw (Say with a color and line thickness), draw that thing, and then the Canvas has no knowledge of that thing: It doesn't know where it is or what it is that you've just drawn, it's just pixels. If you want to draw rectangles and have them move around or be selectable then you have to code all of that from scratch, including the code to remember that you drew them.
SVG on the other hand must maintain references to each object that it renders. Every SVG/VML element you create is a real element in the DOM. By default this allows you to keep much better track of the elements you create and makes dealing with things like mouse events easier by default, but it slows down significantly when there are a large number of objects
Those SVG DOM references mean that some of the footwork of dealing with the things you draw is done for you. And SVG is faster when rendering really large objects, but slower when rendering many objects.
A game would probably be faster in Canvas. A huge map program would probably be faster in SVG. If you do want to use Canvas, I have some tutorials on getting movable objects up and running here.
Canvas would be better for faster things and heavy bitmap manipulation (like animation), but will take more code if you want lots of interactivity.
I've run a bunch of numbers on HTML DIV-made drawing versus Canvas-made drawing. I could make a huge post about the benefits of each, but I will give some of the relevant results of my tests to consider for your specific application:
I made Canvas and HTML DIV test pages, both had movable "nodes." Canvas nodes were objects I created and kept track of in Javascript. HTML nodes were movable Divs.
I added 100,000 nodes to each of my two tests. They performed quite differently:
The HTML test tab took forever to load (timed at slightly under 5 minutes, chrome asked to kill the page the first time). Chrome's task manager says that tab is taking up 168MB. It takes up 12-13% CPU time when I am looking at it, 0% when I am not looking.
The Canvas tab loaded in one second and takes up 30MB. It also takes up 13% of CPU time all of the time, regardless of whether or not one is looking at it. (2013 edit: They've mostly fixed that)
Dragging on the HTML page is smoother, which is expected by the design, since the current setup is to redraw EVERYTHING every 30 milliseconds in the Canvas test. There are plenty of optimizations to be had for Canvas for this. (canvas invalidation being the easiest, also clipping regions, selective redrawing, etc.. just depends on how much you feel like implementing)
There is no doubt you could get Canvas to be faster at object manipulation as the divs in that simple test, and of course far faster in the load time. Drawing/loading is faster in Canvas and has far more room for optimizations, too (ie, excluding things that are off-screen is very easy).
Conclusion:
SVG is probably better for applications and apps with few items (less than 1000? Depends really)
Canvas is better for thousands of objects and careful manipulation, but a lot more code (or a library) is needed to get it off the ground.
HTML Divs are clunky and do not scale, making a circle is only possible with rounded corners, making complex shapes is possible but involves hundreds of tiny tiny pixel-wide divs. Madness ensues.
I have past content from the following link.
Please see this link for more details
HTML5 Canvas vs. SVG vs. div
I am building a node graph in a QGraphicsView and I am currently implementing panning.
I used the following question "how to pan images in QGraphicsView" to start but the panning is limited by the scrollbar range.
I also tried the translate method but it gives the same result. The view is limited to a certain rectangle.
I would like to pan without limits, the graph can becomes quite large and it is useful to be able to work in different area of the scene (one graph here, another graph over there, etc).
If you take a look at this video, at the 3 minute mark you'll see the demonstration panning the screen. The application here is one I developed and although it doesn't show it, the real estate of the board appears limitless when panning.
What I did for this was to create a QGraphicsScene of 32000 x 32000 and start the application with the view at the centre of the QGraphicsScene. The test team spent ages trying to pan to the edge of the graphics scene and everyone gave up before getting there - perhaps the scene could have been smaller!
The scroll bar policies are set to off and translation is done by moving the QGraphicsView via its translate function, passing in the delta of either touch, or mouse movement that is applied in the mouseMoveEvent.
Done this way, you need not worry about exceeding the scroll bar range and there was no problem creating a very large QGraphicsScene as it's just a coordinate space.
I came across the same issue. However, setting the scene to something big and leaving it I do not think is the best option. I have developed a dynamic way of changing the scene size so it lets you move freely. You can find it in this other stack overflow answer.
You want to plot graphs. Try out this Qt library - QCustomPlot , it will save you hours of hard work.
I am using wxWidgets to draw a large flow chart, i.e. 625 x 26329 pixels. The program was transported from Qt to wxWidgets. It is easy in layout with a main frame which has a customized scroll window inside. The scroll window draws part of the chart every time within updated client region.
Now Qt and wxWidgets make much difference. When scrolling vertically with mouse rolling, Qt refreshs painting the chart very smoothly, while wxWidgets is slowly with flicker.
Can anyone tell me how to make the painting efficiently?
Are you sure it's slow? I would be wondering, I encounterd a different experience.
You mention flickering. Flickering is mostly result of too many refresh calls.
To prevent this you must use double buffering and this is the key.
Double buffering means to draw all stuff offscreen into a image / bitmap and after everything is drawn the image/bitmap is drawn fully (this is done really fast so no flickering :)! ).
Qt uses for default double buffering. That's why it looks everytime smooth.
However the downside of this approach is that it consumes performance.
wxWidgets doesn't bound you to that. Instead it says, it's your task to get double buffering.
Also you should look whether you aren't clipping the region you're drawing. Clipping under Windows with wxWidgets gave me a really better performance.
PS:
Yes, old question but I think it's still needed to know how the facts are.
I've started learning flex and as a first project I've created a component from the example found here component with which I call into the main application (web based).
When I rotate the image it goes well,
however, when I resize the application, my component which fills the application container ie width, height 100%, seems to make the rotations calculus based on it's previous width and height.
So basically the rotations go wrong when I resize the app. Any ideas on how to fix this?
I had to recalculate the view's perspective point upon the app resize event.
is it possible to use the startMove Method in AS3 and limit the movement only to the y-axis?
I want my window only to be dragable vertically.
Thank you for your tips.
I don't think that is possible, given that the actual movement of the window is done by the operating system alone (and I can't think of any application right now that restricts such a movement).
But maybe you can emulate such behaviour by encapsulating your actual application into a different window. You could then change the actual application size to the full screen and make it transparent and use startDrag to emulate the dragging of the inner window. Because with that function you can specify boundaries in which the movement is allowed.
I don't know if that will work as you would like it to, however.