LiveCode 6.6 very slow on Retina MacBookPro

Neil Roger neil at runrev.com
Wed Mar 26 05:35:47 EDT 2014


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<lists at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list