Try SnagIt for screen shots. It's really very good. -jct
On 01/06/2013, at 10:24, Daniel Zwolenski <zon...@gmail.com> wrote: > Can anyone recommend any good screen capture software for windows? Not sure > it would capture this problem but it would be useful for some of the other > problems I'm seeing in the TD game that I can't seem to reproduce in small > snippets of code. > > If I had to describe what I was seeing I would say that the movement of the > box as a whole across the path is quite smooth, no jumping or skipping, > etc. > > The visual bit that puts me off is that the border line visually appears to > 'dim' and 'shimmer' slightly. I think perhaps it is the dimming that makes > it the most noticeable, It's almost like the border has gone from black to > a soft grey (which from the sounds of it, it is). Maybe it's as simple as > the crack filling (or whatever) being just a shade darker or something. > When the animation stops and turns around it jumps from grey to crisp black > and this highlights the change. Possibly if this colour change transition > was minimised it would be less noticeable, hard to say. > > The 'shimmering' is that the line gets ever so slightly (but just enough > to be noticeable) fatter at times, almost making it look like the line is > wobbling. I wouldn't say this is pronounced but combined with the dimming > the two affects just make it look on the amateur side of things. > > With the drop shadow, it's almost like the shadow is lagging a frame behind > the shape. So on the way down, the shadow overlaps with the inside of the > box. On the way up, the there is a small gap (or possibly solid gray) line > or two of space between the box and the shadow. Perhaps this might be the > smoothing of the border doubling up with the alpha of the drop shadow > making it look solid. Just guessing though. > > If I fill the box with a darkish color (blue) the shimmering is barely > detectable and with yellow it is less pronounced. Could it be that the > shimmer is more pronounced to the eye if it is on the 'inside' of the box. > Maybe if the inside of the border was kept crisp the eye is ok with the > outside being soft (typically where shadow is, etc)? I don't know. > > If I speed up the animation the problems are much less noticeable but > that's probably just that the eye doesn't have time to process it all. If I > slow down the animation (10 seconds) then the shimmer is still noticeable, > and it may be my eyes playing tricks or just coincidence but it seems worse > just for last few pixels before the animation ends and turns > around. Interestingly on the JScript one at this speed the jerkiness is > more noticeable - in line perhaps with your comments that there are > trade-offs either way with the various options. It would be nice if we all > had retina displays and didn't have to worry about this sort of stuff. > > Been staring at it too long though. It's hard to know what's perception and > what's reality sometimes. > > Also, keep in mind that I'm on latop using it's monitor and traditionally > these are not the nicest rendering - perhaps my symptoms are linked to that > aspect too. > > > > > On Sat, Jun 1, 2013 at 9:52 AM, Richard Bair <richard.b...@oracle.com>wrote: > >> The text in PowerPoint is very likely outlines (treat the text as shapes) >> since there isn't much text per slide and its usually very large (in fact >> most render engines stop rendering text as glyphs at a given size -- for us >> it is > 80pt.). Hmmmm. I wonder if you used an 81pt font and scaled it down >> what that would look like? >> >> I'm curious on the animated box though as to what you are seeing that you >> like. Is it pixel snapping but its moving fast enough that it looks OK? Or >> is it that the AA algorithm is "better" for this case? If you did a screen >> capture would it be high enough quality to show exactly what it is you see? >> >> Richard >> >> On May 31, 2013, at 4:26 PM, Daniel Zwolenski <zon...@gmail.com> wrote: >> >>> I just did some animated text scaling in PowerPoint and it was >> beautiful. If jfx did that you'd have no complaints from me. >>> >>> Is it worth me putting up the PPS file for comparison? Can you open PPS >> on Mac? >>> >>> I did the box one too and it was roughly on par with jscript one, though >> the drop shadow seemed slightly less jumpy. >>> >>> >>> >>> >>> On 01/06/2013, at 9:08 AM, Hervé Girod <herve.gi...@gmail.com> wrote: >>> >>>> We used the second method in a case where we painted animated Swing >> hierarchies in an external OpenGL context, each character associated bitmap >> was cached when it was necessary to draw the Glyph. The result seemed ok to >> us. Now I'm thinking that we could have done the same thing in pure Java >> rather than using our outlines ;) >>>> >>>> Sent from my iPad >>>> >>>> On 1 juin 2013, at 00:43, Richard Bair <richard.b...@oracle.com> wrote: >>>> >>>>> Yes, and sounds like what we want to do with Text. Basically in your >> swing example you were treating the text as outlines rather than glyphs. It >> draws much nicer -- but also much slower. >>>>> >>>>> The other option is to treat them as images and not snap-em. Not as >> nice but probably quite decent for a lot of stuff and a *lot* faster. >>>>> >>>>> On May 31, 2013, at 3:10 PM, Hervé Girod <herve.gi...@gmail.com> >> wrote: >>>>> >>>>>> I don't know if there is the same behavior in JavaFX as in Swing, but >> using Swing for complex animated rendering of texts, we discovered that if >> we used the standard way of daring the strings in a Graphics2D, there was a >> kind of Jitter on each String when moving or rotating the texts, the >> letters seemed to move relatively to each other. >>>>>> >>>>>> To avoid this effect, we used a TextLayout and cached the Strings >> Layouts when they changed and draw their outline Shapes. With this method, >> there was no Jitter at all. Perhaps this is the same case with the two >> methods you mention with these Microsoft links. >>>>>> >>>>>> Herve >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> On 31 mai 2013, at 22:57, Richard Bair <richard.b...@oracle.com> >> wrote: >>>>>> >>>>>>> Felipe found these links: >> http://msdn.microsoft.com/en-us/library/windows/desktop/ee663563(v=vs.85).aspx >> http://msdn.microsoft.com/en-us/library/windows/desktop/dd756767%28v=vs.85%29.aspx >>>>>>> >>>>>>> I followed the 2nd link to run in Parallels. I'm not sure to what >> extent it is the same as what you'd see on dedicated hardware, but I >> thought it would be good for you to see what kind of options DirectWrite >> provides (and to know that Felipe is working on the DirectWrite backend for >> text rendering on Windows). >>>>>>> >>>>>>> Running the "Default" rendering method gives predictably crappy >> looking animated text. Predictable in that MS is doing the same thing we >> are by default -- focusing on producing crisp text. Their crappy might be >> better or worse than our crappy, but in both cases it is crappy when >> animated :-). The "Outlines" method is very nice (and much slower). I >> couldn't run the A8 method on Parallels (it just didn't draw anything). >>>>>>> >>>>>>> Give a play and see what the native system is doing. We need some >> kind of API (as linked in your JIRA issue) to allow you to easily pick >> which method you want. >>>>>>> >>>>>>>> Perhaps it is a windows issue. Does seem like a few of the people >> reporting problems in this thread are on windows, and without those lovely >> high-res Mac displays that make everything look so pretty. On my machine >> there is no way you could say the jfx one is on par with the jscript one. >> I'd have a hard time convincing anyone to use jfx over even lowly jscript >> using that incredibly basic showdown I put together. >>>>>>> >>>>>>> We have a mix of systems but I personally have only a Mac + >> parallels (and when it comes to performance you really can't draw any >> accurate conclusions when running in a VM). >>>>>>> >>>>>>>> How often do you personally run something like ensemble on windows? >> It could be that we're seeing big issues and you're seeing minor ones, >> hence out angst at how casually these issues are treated (two bugs I spent >> hours narrowing down and reproducing got closed in around 10 minutes - was >> the code run on the environment it was reported to be found on in this >> time?). Might be worth you having an eyeball just to see. >>>>>>> >>>>>>> I know Kevin and Jonathan have Windows machines. But this is a good >> point we need to make sure we run on a similar environment. >>>>>>> >>>>>>>> Regarding the Text vs Label thing, I'm not sure I get what that's >> about. My primary use with animations is to do ipad like transitions of >> rich widgets containing labels, buttons, tables, etc. So a panel of buttons >> might slide in left, a document might get folded up and put in a rubbish >> bin, or a dialog might grow out of a button that was clicked. Are you >> saying smooth animations are not intended to be used on complex node graphs >> like this? >>>>>>> >>>>>>> Usually when animating a page of stuff, the best way to get good >> performance (on desktop and mobile) is to first set cache=true on the panel >> being animated, animate the thing, and then turn cache=false on the panel. >> In that case, you won't see any of these issues. But I think you are right >> that Labeled things should have a setting to indicate the way they render >> their text just like the Text node should. >>>>>>> >>>>>>>>> JS is driving tis animation and not CSS? >>>>>>>> >>>>>>>> Is this a question about the HTML I put up? If so then the answer >> is jquery is used to animate between a start css style and an end css style >> (just view source on the HTML, it's about 10 lines of code). How it does >> this you would have to look at jquery's animate method. I know as much >> about it's internals as I do about JFX's. >>>>>>> >>>>>>> Right, my thought was whether the difference between what I see on >> Mac vs. what you see on Windows is based on the browser engine (but I tried >> chrome, so maybe not). When JS is driving the animation you often get >> different performance / behavior than when CSS is driving it. >>>>>>> >>>>>>> Richard >> >>
