These are chat archives for bigdataviewer/bigdataviewer-core

Oct 2017
Philipp Hanslovsky
Oct 24 2017 19:33

@tpietzsch What is the rationale behind choosing ARGBScreenImage[][] for renderImages and screenImages, and BufferdImage[][] for bufferedImages in the MultiResolutionRenderer?
In principle, you could have all of these as ArrayImg< ARGBType, IntArray >[][], and just copy into a new BufferedImage before drawing to the screen, right? Was your decision to use the classes as above to avoid this additional copy? Or are there other effects that I am not aware of?

I am currently trying to write a ViewerPanelFX that is essentially the ViewerPanel in JavaFX, and I ran into the problem that the JavaFX WritableImage does not share data when you pass an int[] (instead, the data is copied), and thus I cannot just c&p ARGBScreenImage and replace occurences of BufferedImage with WriableImage. In particular, this line would fail:

I found a (well hidden, since non api) interface PlatformImage, which I could probably implement to get around this. I am debating with myself, if just using ArrayImg< ARGBType, IntArray >[][] as described above, and just create a WritableImage before drawing onto the screen.

Philipp Hanslovsky
Oct 24 2017 20:03
I just found out that I cannot draw a PlatformImage into a GraphicsContext2D (all javafx), bummer.
I'll need to figure out how to get around that, then.
Oct 24 2017 20:34
@hanslovsky Yes, the idea is to avoid the additional copy
PlatformImage is off-heap probably
maybe in a texture
makes sense
you'll have to copy I think
Philipp Hanslovsky
Oct 24 2017 20:36
Yes, that is pretty much what it looks like now :(
Well, finally, I see something on the screen :D
It is far from what it should be, but I am getting there.