Hi All,
Thank you for all of your feedback in regards to LiveCode 6.6 and retina
displays. We are aware of the performance hit our retina users are
experiencing and are working fast on implementing various optimizations.
There is a workaround that you may be interested in that I discovered
when testing 6.6. last night and it involves manually selecting the
resolution of your display, instead of the default "best for display" or
"scaled".
The following is a link to the free version of QuickRes that will allow
you to do this without you having to poke about with the OS.
http://techsupport.on-rev.com/QuickRes.app.zip
The app basically brings back the removed functionality of selecting a
specific resolution and allows you to select up to the native resolution
of a retina display which is 2880x1800 (although this does give you lots
of space to work with, all screen items are tiny)
Once you set a resolution from this app, you should notice a significant
performance increase in 6.6
Kind Regards,
Neil Roger
--
RunRev Support Team ~ http://www.runrev.com
——
On 26/03/2014 06:03, Kay C Lan wrote:
On Tue, Mar 25, 2014 at 9:11 PM, Trevor DeVore<li...@mangomultimedia.com>wrote:
retina = a lot more pixels
Take a look at this blog post from Mark Waddingham which provides some
background and the solution that is being worked on:
That makes sense but it doesn't add up. I'm on Retina display and never
noticed any sluggishness with 6.6. Still I downloaded Rolf's stacks and
sure enough when I rapidly adjust the size of the stack the 6.6 stack is
jittery in it's adjustment and lags behind the mouse by some distance. But
the 6.5 stack behaves nicely on my retina display, so clearly it's possible.
The problem to me appears to be 6.6 attempts to apply retina resolution
100% of the time which is just a massive waste of cycles. Look at any
individual frame of a movie and for anything moving it's blurry, but a
human can't tell that when the movie is played.
Whilst I accept that there would be times when a developer needs a stack to
be rendered at full resolution 100% of the time, I would imagine for the
vast majority of cases, like Rolf's resize stack example, if the stacks
were rendered at 6.5 resolution during transit and at 6.6 resolution when
static, no one would ever notice the reduction in resolution during these
moves.
I have a system preference to chose if my graphics run at full speed for
faster processing or at a lower speed for better battery life. Seems that
LC needs something similar.
on mouseUp
screenRes low --6.5 behaviour, resets to native (6.6) when script ends -
like lock screen
handlerToMovesStuff
OR
on mouseUp
lock screen
handlerToMoveStuff
unlock screen with viual effect "dissolve" and screenRes Low
-- don't need the intermediate frames to be full res
end mouseUp
--screenRes reset to native so engine will complete the render of the now
static stack at native res.
Give us the scriptable option to apply either.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
