Source code for JavaFX UI controls now available on openjfx

[Roman Kennke]

Hi Kevin,

> As has been pointed out, anything like a Canvas2D or a SwingView will
> need to be done in such a way that the core APIs have no
> Java2D/Swing/AWT dependencies.

Yep, I think I mentioned this ;-) What is considered core APIs and what
is not? Is ui-controls core APIs? (If yes we can stop talking about
SwingView until we get hands on some non-core API.)

> In any case, until more of the platform is open it will be hard to
> integrate this in a way that won't produce throw-away code, or have to
> be refactored later.

Yeah, that's what I was thinking. On the other hand, the throw-away code
would mostly center around the painting which will need to be improved
as soon as the platform provides us something better than the
Image(View) that we use for now. There are lots of other things in the
SwingView code that will stay (I guess) which is all of the event
handling, ProxyWindowPeer and glue code. I'd think it'd be worth
integrating what we have now (if we can, considering the first part of
the email), maybe in a package name space that is not public, and focus
on getting out the relevant pieces of remaining code and polishing up
the things. (Guys, you want to do an open source project, don't just
throw out code drops and do NIH fluff... ;-) )

Cheers, Roman


> -- Kevin
> 
> 
> Roman Kennke wrote: 
> > > I am not the right person to answer this question but Richard said that 
> > > Jasper has been working
> > > on this for a week or so and from what I have read it sounds to me as if 
> > > this could be a very
> > > efficient implementation.
> > >     
> > 
> > It's not clear from this thread if there's already work being done on
> > this, or if they are only thinking about possible solutions. Notably:
> > 
> > "But then we thought we were freaking idiots for not just doing a
> > Canvas2D Node in the embed package that had normal AWT APIs. In the
> > first instance it could be dumb and just do an image copy, and then get
> > upgraded to do direct texture stuff (there is some additional
> > complication there, notably, the splitting of the rendering and event
> > threads, but anyway). In any case it should be more than fast enough. So
> > that's kind of where we're at."
> > 
> > The first part, i.e. image copy, is exactly what we do. We have a
> > BufferedImageView, which renders BufferedImage in JavaFX, and we provide
> > a Graphics2D which can paint on it. It's fairly dumb because we couldn't
> > use or change any internals of JavaFX, but it works well, and it's not
> > *that* slow.
> > 
> > Now... if there's more than this already done in JavaFX @ Oracle, we can
> > scrap this and use what's in JavaFX. On the other side, if this is not
> > the case, our implementation could be used as starting point and
> > improved over time. (We need the other parts of the JavaFX sources to
> > help with this!)
> > 
> > Roman
> > 
> > 
> >