Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (739)
Games in Android Showcase (224)
games submitted by our members
Games in WIP (820)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Off screen rendering, drawing images onto themselves and other shenanigans  (Read 1201 times)
0 Members and 1 Guest are viewing this topic.
Offline Abuse

JGO Ninja


Medals: 60


falling into the abyss of reality


« Posted 2017-09-19 08:53:38 »

I've been enticed by the additional blend modes available in JavaFX to have a little dabble with the API.
However doing low level stuff seems incredibly clumsy?

Am I correct in thinking that drawing to an image in vram (equivalent of Java2D VolatileImage), and then drawing said image onto another image in vram, is now only possible through composition of canvas elements in the scene graph?

If this is the case, how would the current api facilitate cyclic drawing dependency? e.g. drawing a vram image onto itself? (Or, more efficiently, onto an intermediary surface, then onto itself)

A scene graph is all well and good, but shouldn't the API also expose enough of the underlying rendering pipeline so that you can implement a comparable scene graph in user code if JavaFX's offering is inadequate?

I came to JavaFX expecting a Swing 2.0, but without Canvas exposing its underlying vram surface, the API seems needlessly clunky and restrictive for anything more complex than basic image composition.

Am I missing something?
Offline princec

« JGO Spiffy Duke »


Medals: 952
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2017-09-19 09:23:28 »

What you're missing is LWJGL.

Cas Smiley

Offline Abuse

JGO Ninja


Medals: 60


falling into the abyss of reality


« Reply #2 - Posted 2017-09-19 10:40:06 »

What you're missing is LWJGL.

Cas Smiley

Quite, but within the scope of the question?  Kiss

:edit:

Another limitation that's fairly prominent:
if I want to procedurally generate an image (GraphicsContext onto a Canvas seems the only way?), then reuse said generated image multiple places in the scene graph, then I must snapshot it into a WriteableImage?

It makes sense that there's no way of having multiple Canvases in the scene graph share an underlying surface, as that'd break the scene compositing process.

However snapshotting requires the creation of multiple extraneous objects, and significant memory copying; it's slow.
Does the JavaFX API really have no performant way of accomplishing this very basic functionality?!?!

Java2D might have been a terribly API, but at least it was reasonably performant & logical once you got around its over-engineered abstraction, and knew what was actually happening under the hood.

It's maddening that all that seems to be requires is:

WriteableImage.getGraphicsContext()

You'd then be able to leverage JavaFX's more feature-rich graphics pipeline, without being burdened by the limitations of the scene graph.
I've not been so thoroughly confounded by such a fundamentally flawed API design since I did MIDP development a decade ago.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 952
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2017-09-19 11:11:08 »

Yes, JavaFX appears to have basically been designed in a bubble without any input from people who actually needed a modern UI API.

For starters, the creators of JavaFX have entirely ignored existing OpenGL APIs available - open source! - for Java, f.ex LWJGL and JOGL, and instead, pointlessly, totally rolled their own implementations.

Secondly they have inexplicably decided to entirely hide the underlying rendering APIs from the front-facing APIs. This means that nobody else can easily write a plug-in renderer that, for example, used LWJGL instead of the supplied renderers.

That would have gone a long way towards dealing with a whole lot of issues with JavaFX. Specifically there is no efficient, straightforward way to render JavaFX directly into an OpenGL context, so that means integrating JavaFX UIs with existing games engines is hopelessly inefficient, requiring a raft of hacks to get it to work (some one has managed it but it ain't pretty). And that's just the graphics side of things, never mind user input.

Thirdly they've completely hidden most of the skinning / L&F APIs, and where they've not hidden it they've not documented any of it. There are moves to improve this but don't hold your breath. The upshot is that it is very hard to make your own custom controls completely from scratch, and it's very hard to properly customise the L&F of existing controls if not impossible.

All of this is annoying because it could have been avoided.

Cas Smiley

Offline Riven
Administrator

« JGO Overlord »


Medals: 1313
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2017-10-02 19:02:33 »

Call me cynical, but I never even bothered with JavaFX after I saw their first demo: a 2D 'clockwork' comprised of half a dozen (!) rotating opaque arcs. It was stuttering for over 10sec before it became somewhat smooth at 15fps. This was their tech to showoff JavaFX to the world... with the promise that it would become less stuttery, blaming JIT compilers and cold caches. Meanwhile LWJGL was spitting out tens of thousands sprites per frame at 60fps. I lost faith in the competence of the developers right there.

After... applets, poor graphics APIs, poor audio APIs, poor media APIs, why even consider looking at Suns/Oracles clientside tech, where even if they'd succeed, by making it part of the JRE they tied themselves to the backward-compatibility ball-and-chain from day one. We'd have to live forever with every single design-flaw: a revamp would be out of the question, or it would have a clunky API.

Rant. Rant. Rant.

Any project, clientside, serverside or middleware, will have a few flawed iterations. Why ship it in an eco-system that does not allow you to shed your mistakes?


Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline princec

« JGO Spiffy Duke »


Medals: 952
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2017-10-02 21:10:09 »

Reckon I could do a better job of it now Smiley Only taken me 20 years to figure out how, mind...

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 

 
Ecumene (55 views)
2017-09-30 02:57:34

theagentd (78 views)
2017-09-26 18:23:31

cybrmynd (186 views)
2017-08-02 12:28:51

cybrmynd (184 views)
2017-08-02 12:19:43

cybrmynd (191 views)
2017-08-02 12:18:09

Sralse (201 views)
2017-07-25 17:13:48

Archive (757 views)
2017-04-27 17:45:51

buddyBro (891 views)
2017-04-05 03:38:00

CopyableCougar4 (1440 views)
2017-03-24 15:39:42

theagentd (1323 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!