Re: buffer too small

[Jim Graham]

I thought this sounded familiar.  I remember having the thought before, 
but forgot that I actually did something about this already in another 
part of the code.


Both of those sets of methods already exist and they are used in the 
decora ImagePool object to avoid having to allocate a larger scratch 
texture when this over-allocation occurs.  Similar code should be used 
in the updates of the maskTex object.  It would probably be worthwhile 
to immediately adjust it to maxContent dimensions right after it is 
allocated.


That doesn't obviate the fix below, but it adds an optimization...

...jim

On 3/9/16 3:26 PM, Jim Graham wrote:

Hi Johan,

That sounds like the fix then.

Note that there is another optimization issue here that could be
addressed in a follow-on - basically when a larger physical size is
allocated, then we could expand the content dimensions to match what was
allocated.  We would possibly need a new method on the Texture to do
something like "getMaxContentW/H()" and "setContentW/H()", and that
could avoid reallocating a texture in that case...

 ...jim

On 3/9/16 2:01 AM, Johan Vos wrote:

Hi Jim,

Passing the contentWidth to the update() fixes the problem as well, and
if the excessive memory is not needed (as in my proposal), this is of
course much better.
Can I create an issue and suggest the following patch (this is for 8,
but I can do a similar for 9)?

- Johan

---
a/modules/graphics/src/main/java/com/sun/prism/impl/BaseContext.javaThu
Mar 03 03:22:09 2016 +0100

+++
b/modules/graphics/src/main/java/com/sun/prism/impl/BaseContext.javaWed
Mar 09 10:59:35 2016 +0100

@@ -104,7 +104,7 @@

  // since it was bound and unflushed...

  maskTex.update(maskBuffer, maskTex.getPixelFormat(),

 0, 0, 0, 0, highMaskCol, nextMaskRow,

-   maskTex.getPhysicalWidth(), true);

+   maskTex.getContentWidth(), true);

  maskTex.unlock();

  curMaskRow = curMaskCol = nextMaskRow = highMaskCol = 0;

  }


On Tue, Mar 8, 2016 at 10:43 PM, Jim Graham mailto:james.gra...@oracle.com>> wrote:

I think I see the issue.

In the code that calls maskTex.update(...) it passes
maskTex.physicalWidth() as the scan stride of the buffer, but the
scan stride of the buffer is based on the content size, not the
physical size.  Thus, the checkUpdateParams() method overestimates
how many bytes are consumed by the operation.

Changing that to maskTex.getContentWidth() should be fine...

 ...jim

On 3/8/16 6:14 AM, Johan Vos wrote:

We got a number of bug reports (on Android and iOS) reported by
developers
using large images:

java.lang.IllegalArgumentException: Upload requires 2475266
elements, but
only 1549938 elements remain in the buffer

at

com.sun.prism.impl.BaseTexture.checkUpdateParams(BaseTexture.java:354)

at com.sun.prism.es2.ES2Texture.update(ES2Texture.java:640)

at

com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:106)

at

com.sun.prism.impl.BaseContext.updateMaskTexture(BaseContext.java:248)

at
com.sun.prism.impl.ps

.BaseShaderGraphics.renderShape(BaseShaderGraphics.java:482)



I traced this down to the following:

initially, a buffer of [1024 * 1024] is allocated by
BaseContext.validateMaskTexture. When the MaskData becomes
bigger than 1024
(w or h), a new buffer is allocated with capacity [newTexW *
newTexH] with
newTexW and newTexH the new width/height that are passed when
creating a
new Texture. However, the physical size of the texture can be
different --
e.g.

ES2Texture.create (ES2Context, PixelFormat, WrapMode, int, int,
bool) will
in some cases set the real texWidth/height to the next power
of 2.

Subsequently, in next rendering loops when the Texture needs to
be updated,
it is checked whether the capacity of the buffer is large enough
to hold
the texture. In this case, the physical width is passed and the
buffer is
not large enough.

Adding the following two lines in
BaseContext.validateMaskTexture() (line
220) fixes the problem:

  newTexW = Math.max(newTexW,
maskTex.getPhysicalWidth());

  newTexH = Math.max(newTexH,
maskTex.getPhysicalHeight());

Using this patch, the size of the buffer will take the physical
size of the
texture into account. I'm not sure this is the best approach
though.

- Johan

[9] Review request: 8150307: Some tests fail when run on JDK 9 due to use of -Djava.ext.dirs

[Kevin Rushforth]

Hi Dave,

Can you review the following?

https://bugs.openjdk.java.net/browse/JDK-8150307
http://cr.openjdk.java.net/~kcr/8150307/webrev.00/

It should be the last code change needed prior to switching to JDK 9.

Thanks.

-- Kevin

Re: Learning Prism

[Jeffrey Guenther]

Thanks for the tips Johan and Morris! Very helpful!

> On Mar 8, 2016, at 3:22 AM, Johan Vos  wrote:
> 
> Hi,
> 
> I think the best way to get started really depends on your personal 
> preferences (e.g. do you like to read code, docs, diagrams,...).
> I can only comment on how I do it, but others may have other approaches:
> 
> First of all, you can run a simple JavaFX apps with lots of verbose info. See 
> com.sun.prism.impl.PrismSettings for a list, and have at least prism.verbose 
> set to true. This already gives you lots of insight in what is happening.
> 
> Second, you want to know what happens on a pulse. Although many complex 
> things are happening, this is not very hard to detect from the code: start 
> from QuantumToolkit.pulse() and follow it from there. There are basically two 
> main parts: 
> * do the calculations (on the FX Thread) (e.g. look at 
> Scene.ScenePulseListener.pulse())
> * do the rendering (PaintCollector.renderAll() which will ultimately call 
> QuantumRenderer.submitRenderJob() which runs on the Prism thread).
> 
> - Johan
> 
> 
> On Tue, Mar 8, 2016 at 5:34 AM, Felix Bembrick  > wrote:
> +1
> 
> I too would love to dive as deep as possible and improve anything that
> needs improving so some guidance would help greatly!
> 
> Felix
> 
> On 8 March 2016 at 14:45, Jeffrey Guenther  >
> wrote:
> 
> > Hi Devs,
> >
> > I’m interested in learning more about JavaFX’s low level graphics
> > implementation. I’ve spent a couple afternoons source diving in the
> > modules/graphics folder to get the lay of the land and now I think I need
> > some help. Can anyone point me to documentation describing the system’s
> > high level design? Let’s say one or two levels deeper than
> > http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm 
> > ? <
> > http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm 
> > ?>
> >
> > Ultimately, I’d like to gain a better understanding on how JavaFX lays out
> > and renders text for the purposes of understanding how I might be able to
> > contribute to a more advanced text API with support for things like kerning.
> >
> > Secondly, can anyone explain to me how shaders are compiled and passed
> > down to the graphics layer? I’d like to gain a better understanding of how
> > a JavaFX programmer could leverage/add to Prism such that we can write
> > custom shaders/GPU kernels for Effects nodes.
> >
> > I realize the graphics system in JavaFX is not for the faint of heart.
> > There’s much going on beneath the surface. I’m willing to dive deep and do
> > the learning to understand the design. Can anyone point me to docs where I
> > can get started? Or maybe which class to start with and work out from when
> > I’m source diving?
> >
> > Jeff
>