API Review RT:17407 Canvas Node
joseph.andresen at oracle.com
Thu Apr 26 18:39:13 PDT 2012
I do not know the details of what you are trying to do,
(How I would do it)
With the canvas or scenegraph version of a stroboscope of a basketball you would have a timeline with keyframes modify an x,y coordinate and
You could also have it add to a list of coordinates (where to draw a basketball).
With canvas you would iterate through these locations and call gc.drawImage(...)
With the scenegraph you would create an imageview for each location, set its location, and add it to the scene.
You could measure performance of both but really there won't be a huge difference, just very different ways of doing the same thing, and some developers
prefer one over the other.
----- Original Message -----
From: pedro.duquevieira at gmail.com
To: james.graham at oracle.com
Cc: openjfx-dev at openjdk.java.net
Sent: Thursday, April 26, 2012 5:49:19 PM GMT -08:00 US/Canada Pacific
Subject: Re: API Review RT:17407 Canvas Node
I still haven't gotten answers to my questions/assumptions (below), though
it seems (according to the latest mailing list posts) that for my question
of drawing a line chart a canvas node would be better. So could you comment
*"Ok, that was an example.. Not easy to come up with one in a small email
message. I'll do another one: suppose you want to draw the stroboscopy of a
moving object (look at the bouncing ball picture at
https://mail.google.com/mail/?shva=1#inbox/136e5072504853e0) - this is not
a far fetched example I actually will need this in an app I'm doing.
Currently you may have to create thousands of nodes, but with the canvas
node you could simply copy and paste an image of the node various times.*
*Correct me if I'm wrong but my basic premise is that whenever you have to
have several equal representations of a node on the scene graph, you would
do better by using immediate mode rendering and copy pasting the image
*I have a doubt though, that relates to my grid example, if I want to draw
a line chart with thousands of lines which is better: using immediate mode
through the canvas node, or a path node?*
*Thanks for the correction, cheers,"*
Also are you (javafx team) considering adding a callback to the canvas node
whenever there is repainting to be done because of areas that have become
Thanks in advance, best regards,
On Thu, Apr 26, 2012 at 1:21 AM, Pedro Duque Vieira <
pedro.duquevieira at gmail.com> wrote:
> Funny thing you said "infinite in dimension with panning" cause that was
> what I really had in mind, and is the real use case I have for an app.
> On Thu, Apr 26, 2012 at 1:05 AM, Jim Graham <james.graham at oracle.com>wrote:
>> If, potentially, the grid was "infinite in dimension with panning", then
>> you'd have to keep recreating the Path every time they panned around. Some
>> might find it easier to just use direct rendering in that case, but using a
>> Path node and recreating it's segments would not be significantly different
>> in terms of amount of work.
>> On 4/25/12 1:01 PM, Richard Bair wrote:
>>> Nah, the way to do this is with a single Path node. Just do a series of
>>> line-to and move-to. No need to use either canvas or rectangles.
>>> On Apr 24, 2012, at 8:45 AM, Pedro Duque Vieira wrote:
>>>>> Regardless of how the implementation discussion ends up, the driving
>>>>> question should be what do developers expect a 2D Canvas to do? I
>>>>> think of
>>>>> things like photoshop, Illustrator, 8 bit arcade games, animations, 2D
>>>>> apps, Flow chart designers and the like.
>>>> Actually there is another scenario which might be common to several
>>>> of apps.
>>>> An example: imagine your app has a background like a grid and the grid
>>>> spacing might change dynamically. If you create this grid right now you
>>>> might have to instantiate thousands of rectangle nodes (each rectangle
>>>> being a grid square) which will degrade performance severely and also
>>>> memory consumption.
>>>> But if you use something like a Canvas node as the background grid,
>>>> everything will be much better.
>>>> Pedro Duque Vieira
> Pedro Duque Vieira
Pedro Duque Vieira
More information about the openjfx-dev