Canvas clip problems
Daniel Zwolenski
zonski at gmail.com
Tue Jun 4 03:28:55 PDT 2013
Finally got round to testing this and setting -Dprism.order=j2d as Scott
makes the smear go away.
On Sun, Jun 2, 2013 at 11:16 AM, Scott Palmer <swpalmer at gmail.com> wrote:
> Try
> -Dprism.order=sw
> with JavaFS 8
>
> or
> -Dprism.order=j2d
> with JavaFX 2.2
>
> to see if the clipping issue goes away.
>
> Also try -Dprism.dirtyopts=false to see if that fixes the smearing.
>
>
> On Sat, Jun 1, 2013 at 9:14 PM, Scott Palmer <swpalmer at gmail.com> wrote:
>
>> This looks like it may be related to the clipping issue that I'm having
>> (the one that forces me o use the software pipeline in JavaFX 8 or the j2d
>> pipeline in JavaX 2.2)
>>
>> https://javafx-jira.kenai.com/browse/RT-30591
>>
>> I'll try to do the same screencast thingy, as the still in my report
>> don't do justice to the problem.
>>
>> Scott
>>
>>
>> On Sat, Jun 1, 2013 at 8:55 PM, Richard Bair <richard.bair at oracle.com>wrote:
>>
>>> "Cheese" (the smear) should never be possible. It means that the clip
>>> used on the device is wrong for some reason, and therefore some area of the
>>> screen was not being repainted that needed to be. In Swing (or Android or
>>> any other immediate mode API) it is possible that your app could have a bug
>>> that causes this, but with the scene graph the responsibility is with JFX
>>> not to mess up the dirty regions.
>>>
>>> My guess is this is related to the other issue you already filed about
>>> the "z order" rendering issue (which is also related to the clip being
>>> wrong). It might be worth putting the link to the screencast on that bug
>>> report.
>>>
>>> Richard
>>>
>>> On Jun 1, 2013, at 3:21 PM, Daniel Zwolenski <zonski at gmail.com> wrote:
>>>
>>> > Here is one I can't reproduce in smaller code.
>>> >
>>> > http://www.screencast.com/t/AJZjx1TjFT
>>> >
>>> > You can see that when the enemies start off the canvas they end up
>>> leaving
>>> > a smear behind. When they leave the canvas at the other end they also
>>> > smear.
>>> >
>>> > I suspect it's something to do with the clipping code used in the game
>>> but
>>> > I haven't been able to narrow it down (and this area I was a bit flaky
>>> on
>>> > and I think Richard did the starting setup for).
>>> >
>>> > It's probably a case of clipping properly, but should this sort of
>>> > behaviour be even possible to occur?
>>> >
>>> > p.s. thanks for the Camtasia tips - nice product.
>>>
>>>
>>
>
More information about the openjfx-dev
mailing list