JDK-8093993 : Camera regression on devices that lack non-power-of-2 texture support
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-04-23
  • Updated: 2015-06-12
  • Resolved: 2013-04-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Duplicate :  
JDK-8124814 - Text regression in graphics-scrum #1050
Relates :  
JDK-8095217 - [D3D] Rendering incorrect on graphics cards without non-power-of-two support
Relates :  
JDK-8117362 - Viewport is not handled correctly on devices that lack non-power-of-2 texture support
Description
Change set to fix RT-29640 has caused a disruption with EGL rendering
Comments
Windows uses the D3D pipeline. The short answer is that for reasons unrelated to this bug, devices without non-power-of-2 support will not work properly on Windows. Since we have no such devices on which Prism is supported, this is not a real problem.
12-02-2014
Looks OK on my Ubuntu 12.04 x64 Intel HD on b129 Looks like ot's some corner case issue possible. I will open separate issue for that. This will be closed.
12-02-2014
I still able to reproduce the bug on Windows 7 x64 with the latest build (b129) If running the attached jar with -Dprism.forcepowerof2=true, image is stretched vertically. If running without additional keys, app looks fine.
12-02-2014
PathAnimation is in apps/internal/PathAnimation if you have access to internal repo. I'm attaching the jar file just in case you don't have the repo. setup.
23-01-2014
Where to take PathAnimation? (direct link to jar is preferable)
23-01-2014
Pushed the above patch, changeset 7cbe210dea3b.
24-04-2013
Attaching a diff (potTexture.diff) which fixes the issue for all cameras without having to re-add the validate methods.
24-04-2013
Hi Kevin, Ensemble, our shipping demo, has samples that require PerspectiveCamera such as rotating cubes.Can we pass SQE without fixing PerspectiveCamera?
24-04-2013
Note that we don't need to worry about PerspectiveCamera in the short term. Longer term, I am not certain that we want to go back to the route of having validate methods for normal cameras (although that might be a solution). In any case, what we need is a way to rationalize the fact that the RTT being rendered into is bigger than the viewport. This has come up before and may indicate the need for an RTT to have an "effective" size or similar. Alternatively, we need some way to set the viewport to match the content size of the RTT.
24-04-2013
I ran out of time today. Assigning to Pavel so he can continue to work on this issue he time tomorrow.
24-04-2013
Attached is a partial fix. NPOT is now supported on ParallelCamera but not PerspectiveCamera. We need a validate method in PerspectiveCamera to compute the projVewTx in order to support NPOT.
24-04-2013
It appears to be a mismatch between the viewport and the transformation matrix when rendering into the RTT (although there may be more to it than that). Chien is looking into this now.
23-04-2013
This affects embedded, but is reproducible on desktop system without non-power-of-2 texture support (NPOT). There is an existing prism setting to force power-of-two only textures: java -Dprism.forcepowerof2=true ... If you run PathAnimation with this setting then it will look just like the screen shots that David captured.
23-04-2013