Re: acceleratedRendering bugs

2019-03-30 Thread JJS via use-livecode
I just tested a stack on Andorid with lots of input fields where i 
turned the accelerated off everytime.


But this fix now works great. So i can leave it on, Thanks a lot!


Op 27-3-2019 om 01:35 schreef J. Landman Gay via use-livecode:
I'm sending years worth of gratitude and appreciation. You aren't the 
only one who was bothered by this bug.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On March 26, 2019 5:11:23 PM Monte Goulding via use-livecode 
 wrote:


Aha! This one has vexed me for a while now. I thought I had it 
previously but the issue turned out to be somewhere completely 
different to where I was looking!


On 27 Mar 2019, at 4:23 am, JJS via use-livecode 
 wrote:


BUG 10881 seems solved now for the accelerated rendering, it solves 
the pushed up screen of a stack after the keyboard popped up


Thanks Monte!

Very Nice!


___
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


___
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


Re: acceleratedRendering bugs

2019-03-26 Thread J. Landman Gay via use-livecode
I'm sending years worth of gratitude and appreciation. You aren't the only 
one who was bothered by this bug.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On March 26, 2019 5:11:23 PM Monte Goulding via use-livecode 
 wrote:


Aha! This one has vexed me for a while now. I thought I had it previously 
but the issue turned out to be somewhere completely different to where I 
was looking!


On 27 Mar 2019, at 4:23 am, JJS via use-livecode 
 wrote:


BUG 10881 seems solved now for the accelerated rendering, it solves the 
pushed up screen of a stack after the keyboard popped up


Thanks Monte!

Very Nice!


___
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


Re: acceleratedRendering bugs

2019-03-26 Thread Monte Goulding via use-livecode
Aha! This one has vexed me for a while now. I thought I had it previously but 
the issue turned out to be somewhere completely different to where I was 
looking!

> On 27 Mar 2019, at 4:23 am, JJS via use-livecode 
>  wrote:
> 
> BUG 10881 seems solved now for the accelerated rendering, it solves the 
> pushed up screen of a stack after the keyboard popped up
> 
> Thanks Monte!
> 
> Very Nice!

___
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


Re: acceleratedRendering bugs

2019-03-26 Thread JJS via use-livecode
BUG 10881 seems solved now for the accelerated rendering, it solves the 
pushed up screen of a stack after the keyboard popped up


Thanks Monte!

Very Nice!

Op 12-3-2019 om 14:00 schreef Sphere via use-livecode:

Thanks for your reply Randy.
Nice app you made.

I noticed it is sensitve and that the DG2 group with images and text 
got even slower.
So i have to play some more to get it more smoother as it looked more 
cloggy when scrolling.
i can try the max and see if it will have some effect. I also tried it 
on BlueStacks after i saw the hint from Richmond.
That should be very fast, as we have to wait on 9.1 before we can use 
the fast x86 emulator.

But even in BlueStacks the DG is slow and cloggy.

Randy Hengst via use-livecode schreef op 2019-03-12 11:38:

My work is only with  iOS. So, no comments about Android…

But, I found while working a recent iPad app (with many moving
controls) that I needed to adjust the layerMode to dynamic and back to
static after the move.

I also increased the compositorCacheLimit as you noted… only I went up
to 256*1024*1024.
I made this adjustment in the startUp handler.

I even needed to up the compositorCacheLimit while working in the IDE.
I made that adjustment in the message box.

I didn’t make any changes relative to compositorTileSize or 
compositorType.


The app I was developing when I first started making these adjustments
is free (if that will help understand my context) ….
here is the Apple App Preview page:
https://itunes.apple.com/us/app/begotten/id1431461736?mt=8


be well,
randy
www.classroomFocusedSoftware.com


On Mar 11, 2019, at 4:13 PM, JJS via use-livecode 
 wrote:


i was playing a bit with the separate command you can use instead of 
acceleratedrendering (on Android mobile)


compositorTileSize,layerMode,compositorType,compositorCacheLimit

and noticed that setting compositorType to opengl for android causes 
the black out screen


i'm not sure yet about compositorTileSize what it does on speed

the compositorCacheLimit needs to be big like 64*1024*1024 for 64MB 
according calculation in the dictionary, if you set it small it gets 
slow updated


now i'm not sure if i need the separate commands to be set empty in 
the closecard (to prevent upshifting on other cards when using 
keyboard) or that setting the acceleratedrendering to false would be 
enough.


till now i set the accelerated rendering on and off depending if i 
need keyboard on the card



anyone else have experience with these commands?



___
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


___
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

Re: acceleratedRendering bugs

2019-03-12 Thread Sphere via use-livecode

Thanks for your reply Randy.
Nice app you made.

I noticed it is sensitve and that the DG2 group with images and text got 
even slower.
So i have to play some more to get it more smoother as it looked more 
cloggy when scrolling.
i can try the max and see if it will have some effect. I also tried it 
on BlueStacks after i saw the hint from Richmond.
That should be very fast, as we have to wait on 9.1 before we can use 
the fast x86 emulator.

But even in BlueStacks the DG is slow and cloggy.

Randy Hengst via use-livecode schreef op 2019-03-12 11:38:

My work is only with  iOS. So, no comments about Android…

But, I found while working a recent iPad app (with many moving
controls) that I needed to adjust the layerMode to dynamic and back to
static after the move.

I also increased the compositorCacheLimit as you noted… only I went up
to 256*1024*1024.
I made this adjustment in the startUp handler.

I even needed to up the compositorCacheLimit while working in the IDE.
I made that adjustment in the message box.

I didn’t make any changes relative to compositorTileSize or 
compositorType.


The app I was developing when I first started making these adjustments
is free (if that will help understand my context) ….
here is the Apple App Preview page:
https://itunes.apple.com/us/app/begotten/id1431461736?mt=8


be well,
randy
www.classroomFocusedSoftware.com


On Mar 11, 2019, at 4:13 PM, JJS via use-livecode 
 wrote:


i was playing a bit with the separate command you can use instead of 
acceleratedrendering (on Android mobile)


compositorTileSize,layerMode,compositorType,compositorCacheLimit

and noticed that setting compositorType to opengl for android causes 
the black out screen


i'm not sure yet about compositorTileSize what it does on speed

the compositorCacheLimit needs to be big like 64*1024*1024 for 64MB 
according calculation in the dictionary, if you set it small it gets 
slow updated


now i'm not sure if i need the separate commands to be set empty in 
the closecard (to prevent upshifting on other cards when using 
keyboard) or that setting the acceleratedrendering to false would be 
enough.


till now i set the accelerated rendering on and off depending if i 
need keyboard on the card



anyone else have experience with these commands?



___
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


___
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

Re: acceleratedRendering bugs

2019-03-12 Thread Randy Hengst via use-livecode
My work is only with  iOS. So, no comments about Android…

But, I found while working a recent iPad app (with many moving controls) that I 
needed to adjust the layerMode to dynamic and back to static after the move.

I also increased the compositorCacheLimit as you noted… only I went up to 
256*1024*1024.
I made this adjustment in the startUp handler.

I even needed to up the compositorCacheLimit while working in the IDE.
I made that adjustment in the message box.

I didn’t make any changes relative to compositorTileSize or compositorType.

The app I was developing when I first started making these adjustments is free 
(if that will help understand my context) …. 
here is the Apple App Preview page:  
https://itunes.apple.com/us/app/begotten/id1431461736?mt=8
   

be well,
randy
www.classroomFocusedSoftware.com


> On Mar 11, 2019, at 4:13 PM, JJS via use-livecode 
>  wrote:
> 
> i was playing a bit with the separate command you can use instead of 
> acceleratedrendering (on Android mobile)
> 
> compositorTileSize,layerMode,compositorType,compositorCacheLimit
> 
> and noticed that setting compositorType to opengl for android causes the 
> black out screen
> 
> i'm not sure yet about compositorTileSize what it does on speed
> 
> the compositorCacheLimit needs to be big like 64*1024*1024 for 64MB according 
> calculation in the dictionary, if you set it small it gets slow updated
> 
> now i'm not sure if i need the separate commands to be set empty in the 
> closecard (to prevent upshifting on other cards when using keyboard) or that 
> setting the acceleratedrendering to false would be enough.
> 
> till now i set the accelerated rendering on and off depending if i need 
> keyboard on the card
> 
> 
> anyone else have experience with these commands?
> 
> 
> 
> ___
> 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

Re: acceleratedRendering bugs

2019-03-11 Thread JJS via use-livecode
i was playing a bit with the separate command you can use instead of 
acceleratedrendering (on Android mobile)


compositorTileSize,layerMode,compositorType,compositorCacheLimit

and noticed that setting compositorType to opengl for android causes the 
black out screen


i'm not sure yet about compositorTileSize what it does on speed

the compositorCacheLimit needs to be big like 64*1024*1024 for 64MB 
according calculation in the dictionary, if you set it small it gets 
slow updated


now i'm not sure if i need the separate commands to be set empty in the 
closecard (to prevent upshifting on other cards when using keyboard) or 
that setting the acceleratedrendering to false would be enough.


till now i set the accelerated rendering on and off depending if i need 
keyboard on the card



anyone else have experience with these commands?



___
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


Re: acceleratedRendering bugs

2019-03-08 Thread JJS via use-livecode
I checked github, nothing there yet, but... it's a DP1, so hoepfully ti 
will be adressed. Maybe it's not an easy one


Op 8-3-2019 om 17:46 schreef Tom Glod via use-livecode:

Yeah.. accelerated rendering for dg2 and subgroups was moved to release
9.1 a while back.

I'm looking forward to it as well.

several things that can work in the mean time is

* using lower resolution with scaling quality set to normal
* updating images after the grid rows have updated. (this enables scrolling
to be faster)
* large text fields are slow too. so putting in only enough text to
render speeds it up alot

I am very curious about the speed increase of the grid after these AR
changes have been implemented.




On Thu, Mar 7, 2019 at 4:18 PM JJS via use-livecode <
use-livecode@lists.runrev.com> wrote:


Hi,


i saw there are stil 17 bugs open on acceleratedRendering.

Is there any sight on when they will be solved? (or at least the most
bugging ones)

Especially the up shifted screen with the keyboards and the black
screens (even short when switching cards) on mobile.

And could it be cause for slow scrolling of DG's  (with images)?

I know there are some tricks, but in most cases i turn it off and on
again depending what's on the card and if a keyboard has to be used.


Thanks,

Jerry



___
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


___
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


Re: acceleratedRendering bugs

2019-03-08 Thread Tom Glod via use-livecode
Yeah.. accelerated rendering for dg2 and subgroups was moved to release
9.1 a while back.

I'm looking forward to it as well.

several things that can work in the mean time is

* using lower resolution with scaling quality set to normal
* updating images after the grid rows have updated. (this enables scrolling
to be faster)
* large text fields are slow too. so putting in only enough text to
render speeds it up alot

I am very curious about the speed increase of the grid after these AR
changes have been implemented.




On Thu, Mar 7, 2019 at 4:18 PM JJS via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi,
>
>
> i saw there are stil 17 bugs open on acceleratedRendering.
>
> Is there any sight on when they will be solved? (or at least the most
> bugging ones)
>
> Especially the up shifted screen with the keyboards and the black
> screens (even short when switching cards) on mobile.
>
> And could it be cause for slow scrolling of DG's  (with images)?
>
> I know there are some tricks, but in most cases i turn it off and on
> again depending what's on the card and if a keyboard has to be used.
>
>
> Thanks,
>
> Jerry
>
>
>
> ___
> 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


Re: acceleratedRendering

2018-08-02 Thread Sannyasin Brahmanathaswami via use-livecode
I don't know if it would work on a iOS 12, but we has an issue with a complex 
dynamic "draw" on screen..

So we turned of acceleratedRendering  to false temporarily

Then set to back when the drawing was finish

on createWordPuzzle
   if (the acceleratedRendering of this stack is true ) then
  set the acceleratedRacceleratedRendering on createWordPuzzle
   end if
   stopTimer
   hide widget "context"
   loadNewBgImg
   [snip]

# later 

set the acceleratedRendering  of this stack to true

end createWordPuzzle


Brahmanathaswami
 

 Randy Hengst wrote:

I’ve been messing with this slowdown issue … there is a connection between 
having acceleratedRendering set to true… and my objects that move set to 
dynamic. I see the slowdown in the IDE and on the iPad. 

Using LC 9.0.1 RC1 still.

___
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

Re: acceleratedRendering

2018-08-02 Thread Sannyasin Brahmanathaswami via use-livecode
Next week will be fine __

Brahmanathaswami
 

On 8/2/18, 1:23 PM, "use-livecode on behalf of Monte Goulding via 
use-livecode"  wrote:

Given it’s Friday and these patches have yet to be reviewed I very much 
doubt we will be releasing an RC 2 with them in this week. We do have a service 
providing access to nightly builds I believe but I don’t know the full details 
(cost ect) so you could contact support about that if it is of interest.

Cheers

Monte

___
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

Re: acceleratedRendering

2018-08-02 Thread Monte Goulding via use-livecode
> @team-- would it possible to send a new build out this week?  Even it has 
> only this patch
> 
> It is the one thing in Android that is blocking. Everything else you have 
> accomplished on 9.0.1 is fantastic, and I really *need* get an Android 
> version that works one on Google Play asap.   So I need to get this out to 
> beta tester asap

Given it’s Friday and these patches have yet to be reviewed I very much doubt 
we will be releasing an RC 2 with them in this week. We do have a service 
providing access to nightly builds I believe but I don’t know the full details 
(cost ect) so you could contact support about that if it is of interest.

Cheers

Monte
___
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

Re: acceleratedRendering

2018-08-02 Thread Andrew Bell via use-livecode
Panos asked me to file a bug report on what I was experiencing, but I  
haven't been able to nail down the formula yet.


Simply enabling acceleratedRendering would allow my app to launch, but  
things weren't moving or responding as they should have. It does seem  
like some mouseUp messages are getting ignored, but I'm also dealing  
with screen redraw issues when moving objects and groups in time as  
well as using mobileControls (a side navigation that opens up from off  
screen and hides mobile browser).


I'm currently redesigning the navigation so I can get an update out  
the door quickly as users are already complaining about iOS 12  
compatibility. You've given me some insight into the possible problem  
so I can try to work out a proper bug report formula.


--Andrew Bell



From: Sannyasin Brahmanathaswami 
To: How to use LiveCode 
Subject: Re: acceleratedRendering
Message-ID: <5a86d6a0-88c9-4d00-b7d5-749568f74...@hindu.org>
Content-Type: text/plain; charset="utf-8"

FWIW... acceleratedRendering in causing trouble on Android, 9.0.1. RC 1.

Disables "touch" messages in some contexts...

Bug report is in, confirmed.

I've struggling for 2 Years with this (!)

Now on iOS?  Yikes!

I am sure it is a priority with team. Keep fingers crossed.

BR


?On 8/1/18, 4:07 AM, "use-livecode on behalf of Randy Hengst via  
use-livecode" use-livecode@lists.runrev.com> wrote:


Is there some element that goes hand-in-hand with  
acceleratedRendering that I?ve overlooked?







___
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


Re: acceleratedRendering

2018-08-02 Thread Randy Hengst via use-livecode
All,

I’ve been messing with this slowdown issue … there is a connection between 
having acceleratedRendering set to true… and my objects that move set to 
dynamic. I see the slowdown in the IDE and on the iPad. 

Using LC 9.0.1 RC1 still.

The “catch” is that I haven’t been able to reproduce the same problem for a 
demo stack… so, still investigating. If anyone has a thought for something I 
can check out, please share.

be well,
randy
classroomFocusedSoftware.com

> On Aug 2, 2018, at 8:48 AM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Aloha Monte
> 
> You are wonderful! "it groups not redrawing..."
> 
> Right, it's not "touch". Though from a user perspective, suddenly "my swiping 
> doesn't work..."
> 
> And thank you for fixing the returnField error also  [Bug 18395] 
> ReturninField error on android app)
> 
> @team-- would it possible to send a new build out this week?  Even it has 
> only this patch
> 
> It is the one thing in Android that is blocking. Everything else you have 
> accomplished on 9.0.1 is fantastic, and I really *need* get an Android 
> version that works one on Google Play asap.   So I need to get this out to 
> beta tester asap
> 
> BR
> 
> PS...
> 
> would it would also be nice if get the home screen icon to load in iOS at the 
> same time, in an interim patch release. 
> 
> https://quality.livecode.com/show_bug.cgi?id=21451
> 
> On 8/1/18, 5:02 PM, "use-livecode on behalf of Monte Goulding via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
>Yes I just patched it https://github.com/livecode/livecode/pull/6620 
> 
> 
>> FWIW... acceleratedRendering in causing trouble on Android, 9.0.1. RC 1.
>> Disables "touch" messages in some contexts… 
> 
>^ is not a very good description of the issue. The touches are fine. It’s 
> groups not redrawing when scrolled under some circumstances.
> 
> ___
> 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

Re: acceleratedRendering

2018-08-02 Thread Sannyasin Brahmanathaswami via use-livecode
Aloha Monte

You are wonderful! "it groups not redrawing..."

Right, it's not "touch". Though from a user perspective, suddenly "my swiping 
doesn't work..."

And thank you for fixing the returnField error also  [Bug 18395] ReturninField 
error on android app)

@team-- would it possible to send a new build out this week?  Even it has only 
this patch

It is the one thing in Android that is blocking. Everything else you have 
accomplished on 9.0.1 is fantastic, and I really *need* get an Android version 
that works one on Google Play asap.   So I need to get this out to beta tester 
asap

BR

PS...

would it would also be nice if get the home screen icon to load in iOS at the 
same time, in an interim patch release. 

https://quality.livecode.com/show_bug.cgi?id=21451
 
On 8/1/18, 5:02 PM, "use-livecode on behalf of Monte Goulding via 
use-livecode"  wrote:

Yes I just patched it https://github.com/livecode/livecode/pull/6620 


>FWIW... acceleratedRendering in causing trouble on Android, 9.0.1. RC 1.
>Disables "touch" messages in some contexts… 

^ is not a very good description of the issue. The touches are fine. It’s 
groups not redrawing when scrolled under some circumstances.

___
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

Re: acceleratedRendering

2018-08-01 Thread Monte Goulding via use-livecode
Hi Brahma
> 
> I am sure it is a priority with team. Keep fingers crossed. 


Yes I just patched it https://github.com/livecode/livecode/pull/6620 


> FWIW... acceleratedRendering in causing trouble on Android, 9.0.1. RC 1.
> 
> Disables "touch" messages in some contexts… 

^ is not a very good description of the issue. The touches are fine. It’s 
groups not redrawing when scrolled under some circumstances.

Cheers

Monte
___
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

Re: acceleratedRendering

2018-08-01 Thread Sannyasin Brahmanathaswami via use-livecode
FWIW... acceleratedRendering in causing trouble on Android, 9.0.1. RC 1.

Disables "touch" messages in some contexts... 

Bug report is in, confirmed.

I've struggling for 2 Years with this (!) 

Now on iOS?  Yikes!

I am sure it is a priority with team. Keep fingers crossed. 

BR
 

On 8/1/18, 4:07 AM, "use-livecode on behalf of Randy Hengst via use-livecode" 
 wrote:

Is there some element that goes hand-in-hand with acceleratedRendering that 
I’ve overlooked?

___
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

Re: AcceleratedRendering States When Opening and Closing Stacks

2017-09-30 Thread J. Landman Gay via use-livecode

On 9/30/17 12:42 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

Our symptom is, (as you know) the objects for stack A still appear on screen, ( only on 
Android) even if you log for the current top stack and LC engine returns "Stack 
B"  we are seeing the contents of the card for Stack A even after it has been closed…


I've got to think this is a bug. It doesn't happen on desktop or iOS, so 
it would make sense it's something in the Android implementation.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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

Re: AcceleratedRendering States When Opening and Closing Stacks

2017-09-30 Thread Sannyasin Brahmanathaswami via use-livecode
Well …"exactly"

And that is what we want to clarify

if stack A  is open and contents for its front card are buffered.

Now open stack B on top of stack A with Accelerated Rendering on..

Just then…  before we close Stack, for n number of milliseconds we have 
buffered objects for 2 different cards/stacks. N'est ce pas?

So the question is: could this be a problem for Android or not?

Our symptom is, (as you know) the objects for stack A still appear on screen, ( 
only on Android) even if you log for the current top stack and LC engine 
returns "Stack B"  we are seeing the contents of the card for Stack A even 
after it has been closed…

BR


J. Landman Gay wrote:

This is all done at the 
card level and the cache is flushed when the card closes or when the cache 
is full. A stack or card that isn't open has no effect on anything.

Someone correct me if I mangled the concept.

___
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

Re: AcceleratedRendering States When Opening and Closing Stacks

2017-09-30 Thread J. Landman Gay via use-livecode
I doubt the layermode is an issue here. Layermode is relevant only when the 
card is open.


I'm not where I can review Mark's post about it, but I think 
acceleratedRendering basically tells the engine to buffer the content of 
designated controls so they will move smoothly. The layermode tells the 
engine what type of movement will be implemented. This is all done at the 
card level and the cache is flushed when the card closes or when the cache 
is full. A stack or card that isn't open has no effect on anything.


Someone correct me if I mangled the concept.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On September 29, 2017 10:38:58 PM Sannyasin Brahmanathaswami via 
use-livecode  wrote:



It's not set for "everything" only scrolling groups.

How can it be drawing too much? if there is only one scrolling group on the 
card and all other cards, stacks etc are closed or not in view, how does 
having the layermode set in an unopened stack start to "draw too much"


??



Jonathan Lynch wrote:

It seems like having the layermode set to scrolling for everything forces 
it to draw too much stuff. What happens if you only do one at a time?


Mark W would know more. But, I have found one at a time means it only gives 
extra power where it is needed.


___
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


Re: AcceleratedRendering States When Opening and Closing Stacks

2017-09-29 Thread Sannyasin Brahmanathaswami via use-livecode
It's not set for "everything" only scrolling groups.

How can it be drawing too much? if there is only one scrolling group on the 
card and all other cards, stacks etc are closed or not in view, how does having 
the layermode set in an unopened stack start to "draw too much"

??



Jonathan Lynch wrote:

It seems like having the layermode set to scrolling for everything forces 
it to draw too much stuff. What happens if you only do one at a time?

Mark W would know more. But, I have found one at a time means it only gives 
extra power where it is needed.

___
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


Re: AcceleratedRendering States When Opening and Closing Stacks

2017-09-29 Thread Jonathan Lynch via use-livecode
It seems like having the layermode set to scrolling for everything forces it to 
draw too much stuff. What happens if you only do one at a time?

Mark W would know more. But, I have found one at a time means it only gives 
extra power where it is needed.

Sent from my iPhone

> On Sep 29, 2017, at 9:11 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Jonathan:
> 
> The layermode of the scrolling groups is preset to "scrolling" 
> 
> The question is about the sequence as it relates to visual layer rendering
> 
> Open Stack A, turn on acceleratedRendering
> Open Stack B, which also turns on its "own" acceleratedRendering
> Close Stack A, *after* having open B "on top of Stack A
> 
> What are the issues, if any, with turning AcceleratedRendering On and off in 
> the above sequence, especially on Android. 
> 
> a) do we need a "super-nuanced" on and off with careful timing? Seems way too 
> difficult for any newbie unless we have very good documentation.
> 
> OR
> 
> b) is just this simple: 
> 
> acceleratedRendering only affects the visible stack on top and the engine, 
> the vRam/visible view that the user sees of the top stack is totally 
> unaffected by the state of the acceleratedRending of stack A above *during 
> and while* Stack B is opened and rendered on the device
> 
> the latter seems to be the case on iOS, on Android we are seeing a lot of 
> oddities. Debugging is virtually impossible since it works on iOS and 
> Desktop.. 
> 
> On Android, you can start throwing query dialogs.  after opening Stack B and 
> Closing Stack, you do
> 
> put the short name of the top stack into tTopStack
> 
> Answer tTopStack with "OK"
> 
> and you get "B" (the one just opened) but on screen we see Stack A (the one 
> just closed)
> 
> 
> 
> 
> 
> On 9/29/17, 11:34 AM, "use-livecode on behalf of Jonathan Lynch via 
> use-livecode"  use-livecode@lists.runrev.com> wrote:
> 
>Hi Swami,
> 
>I turn accelerated rendering on and off depending on which group the user 
> opens up. 
> 
>Are you setting the layermode of each group as you go?
> 
> ___
> 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


Re: AcceleratedRendering States When Opening and Closing Stacks

2017-09-29 Thread Sannyasin Brahmanathaswami via use-livecode
Jonathan:

The layermode of the scrolling groups is preset to "scrolling" 

The question is about the sequence as it relates to visual layer rendering

Open Stack A, turn on acceleratedRendering
Open Stack B, which also turns on its "own" acceleratedRendering
Close Stack A, *after* having open B "on top of Stack A
 
What are the issues, if any, with turning AcceleratedRendering On and off in 
the above sequence, especially on Android. 

a) do we need a "super-nuanced" on and off with careful timing? Seems way too 
difficult for any newbie unless we have very good documentation.

OR

b) is just this simple: 

acceleratedRendering only affects the visible stack on top and the engine, the 
vRam/visible view that the user sees of the top stack is totally unaffected by 
the state of the acceleratedRending of stack A above *during and while* Stack B 
is opened and rendered on the device

the latter seems to be the case on iOS, on Android we are seeing a lot of 
oddities. Debugging is virtually impossible since it works on iOS and Desktop.. 

On Android, you can start throwing query dialogs.  after opening Stack B and 
Closing Stack, you do

put the short name of the top stack into tTopStack

Answer tTopStack with "OK"

and you get "B" (the one just opened) but on screen we see Stack A (the one 
just closed)



 

On 9/29/17, 11:34 AM, "use-livecode on behalf of Jonathan Lynch via 
use-livecode"  wrote:

Hi Swami,

I turn accelerated rendering on and off depending on which group the user 
opens up. 

Are you setting the layermode of each group as you go?

___
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


Re: AcceleratedRendering States When Opening and Closing Stacks

2017-09-29 Thread Jonathan Lynch via use-livecode
Hi Swami,

I turn accelerated rendering on and off depending on which group the user opens 
up. 

Are you setting the layermode of each group as you go?

Sent from my iPhone

> On Sep 29, 2017, at 1:41 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> We continue struggle with our app on Android and between mobile controls 
> being instantiated or deleted + oddities with acceleratedRendering, + remote 
> bugging not *really* working, it's a bit of a fishing expedition when 
> everything works on desktop and iOS.
> 
> A complete document on accelerated rendering, what it does, impact on the 
> engine, optimal usage etc would be useful. Right now my best option is to 
> look for "acceleratedRendering" Mark Waddington in this list. Maybe we should 
> compile all his replies and submit as a guide addition.
> 
> if your goal is to just improve the performance of mobile scrolling fields 
> and groups, and all cards in stack will have one of both or both of these… 
> then it makes sense to turn on acceleratedRendering in the preopenstack 
> handler… or course there are bugs there and work arounds, wait 200 seconds, 
> Panos "fixIt" … the fact that LC on Android will crash if you go home or app 
> switcher and the acceleratedRendering is on.
> 
> Setting all the above aside, assuming we implement the necessary 
> "hackarounds" questions today are
> 
> 1) Do we need to do this
> 
> on closeStack
> set the acceleratedRendering of this stack to false
> end close stack
> 
> or if you close the stack are all the mysterious overheads "costs" of 
> acceleratedRendering for that stack "wiped" from the engines brain, whether 
> you turn it off or no, with no residual impact on the rendering of views?
> 
> 2) assuming you do run that at close stack…if you open a stack B *before* 
> closing the stack A which has acceleratedRendering set to true   is there a 
> cost in terms of the engine ability to render everything in the newly opened 
> stack, remember we have not closed stack A yes. but stack B is now open "on 
> top"
> 
> OK simple version then is: what is best practice for this scenario
> 
> 1) stack "apples" is open, with acceleratedRendering set to true
> 2) we open stack "oranges" and set the acceleratedRendering of stack this 
> stack (now "oranges") to true
> 3) we close stack "apples"
> 
> how is this best handled, given that we see no problems with this in iOS?
> 
> Brahmanathaswami
> 
> 
> 
> ___
> 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

Re: acceleratedRendering scope

2017-08-21 Thread Mark Waddingham via use-livecode

On 2017-08-21 19:13, Jonathan Lynch via use-livecode wrote:

It is on iOS. Turning it on and off as needed has worked perfectly, so
it is no problem. Thanks for explaining!


Okay - so obviously it hasn't 'got any better' since iOS4 which was when 
we added acceleratedRendering mode... This is slightly irksome! I do 
wonder if there must be a better way of doing what we need to do these 
days on iOS though - after all iOS has things like SpriteKit which 
(IIRC) work in a UIView, and I'd be surprised if they accepted there 
being issues if SpriteKit views were mixed in with normal UIKit views.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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


Re: acceleratedRendering scope

2017-08-21 Thread Jonathan Lynch via use-livecode
It is on iOS. Turning it on and off as needed has worked perfectly, so it is no 
problem. Thanks for explaining!

Sent from my iPhone

> On Aug 21, 2017, at 12:54 PM, Mark Waddingham via use-livecode 
>  wrote:
> 
>> On 2017-08-21 18:51, Jonathan Lynch via use-livecode wrote:
>> Hi Bob- I can report that accelerated rendering "steals" resources
>> from the browser widget. I have to turn it off when displaying a 3D
>> map in the browser widget, then turn it back on for scrolling groups.
>> Otherwise, the map renders in a very clunky way, with large sections
>> very distorted.
> 
> Is this on iOS or Android or both?
> 
> I'm not sure that's to do with any resource stealing - it's more to do with 
> the fact that the mobile OSes don't like mixing OpenGL based views with 
> non-OpenGL based views generally. You can limit the amount of texture RAM 
> accelRendering uses by setting the compositorCacheLimit (I think that's the 
> right property) which is the maximum number of bytes the engine will use for 
> the cache of tiles at any one time.
> 
> On iOS, in particular, putting a normal UIKit view (which the browser widget 
> is) on top of an OpenGL view (which accel render mode uses) tends to make the 
> OS not that happy. Of course, this might entirely depend on device too!
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> 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


Re: acceleratedRendering scope

2017-08-21 Thread Mark Waddingham via use-livecode

On 2017-08-21 18:51, Jonathan Lynch via use-livecode wrote:

Hi Bob- I can report that accelerated rendering "steals" resources
from the browser widget. I have to turn it off when displaying a 3D
map in the browser widget, then turn it back on for scrolling groups.
Otherwise, the map renders in a very clunky way, with large sections
very distorted.


Is this on iOS or Android or both?

I'm not sure that's to do with any resource stealing - it's more to do 
with the fact that the mobile OSes don't like mixing OpenGL based views 
with non-OpenGL based views generally. You can limit the amount of 
texture RAM accelRendering uses by setting the compositorCacheLimit (I 
think that's the right property) which is the maximum number of bytes 
the engine will use for the cache of tiles at any one time.


On iOS, in particular, putting a normal UIKit view (which the browser 
widget is) on top of an OpenGL view (which accel render mode uses) tends 
to make the OS not that happy. Of course, this might entirely depend on 
device too!


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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


Re: acceleratedRendering scope

2017-08-21 Thread Mark Waddingham via use-livecode

On 2017-08-21 18:41, Bob Sneidar via use-livecode wrote:

Hi all.

Since acceleratedRendering is a stack property, does it only apply to
a given stack, and not, for example to a sub stack? What would the
advantage be of having it off? If none, why even have it?


It is per stack, and not inherited.

Whether you get a benefit or not from acceleratedRendering depends on 
your stack. If you don't set the layerMode property on anything, then it 
will generally cause a slight performance penalty (although this perhaps 
needs more direct measurement to compare - particularly between desktop 
and mobile which are very different graphics performance wise).


The benefits of acceleratedRendering come out when you aren't changing 
how any object looks that often, and you have a lot of objects moving - 
or, indeed, when you are moving large objects around, but not changing 
very much of them as you do so.


So, for example, if you emulating visual effects by moving large 
controls around periodically you might well find you get a better 
framerate (particularly on mobile) by turning accelRendering on, setting 
the layerMode of just the moving controls to dynamic, then turning it 
off again.


If you are doing a game with lots of moving objects, then you will 
pretty much always gain advantage from making all the moving object's 
layerMode dynamic; and leaving the scenery / HUD type things as static.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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


Re: acceleratedRendering scope

2017-08-21 Thread Jonathan Lynch via use-livecode
Hi Bob- I can report that accelerated rendering "steals" resources from the 
browser widget. I have to turn it off when displaying a 3D map in the browser 
widget, then turn it back on for scrolling groups. Otherwise, the map renders 
in a very clunky way, with large sections very distorted.

It has to do with overstressing the GPU.

Sent from my iPhone

> On Aug 21, 2017, at 12:43 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
> I meant to say, why not just have it on permanently?
> 
> Bob S
> 
> 
>> On Aug 21, 2017, at 09:41 , Bob Sneidar via use-livecode 
>>  wrote:
>> 
>> Hi all. 
>> 
>> Since acceleratedRendering is a stack property, does it only apply to a 
>> given stack, and not, for example to a sub stack? What would the advantage 
>> be of having it off? If none, why even have it? 
>> 
>> Bob S
> 
> 
> ___
> 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


Re: acceleratedRendering scope

2017-08-21 Thread Bob Sneidar via use-livecode
I meant to say, why not just have it on permanently?

Bob S


> On Aug 21, 2017, at 09:41 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hi all. 
> 
> Since acceleratedRendering is a stack property, does it only apply to a given 
> stack, and not, for example to a sub stack? What would the advantage be of 
> having it off? If none, why even have it? 
> 
> Bob S


___
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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-22 Thread Randy Hengst
Hi Scott and Jacque,

Thanks for the help… 

I've been exploring colorOverlay… looks like I can make it work.

be well,
randy
-
On Jul 22, 2012, at 12:14 AM, Scott Rossi wrote:

 The first question to Randy would be, why do you want to change the image to 
 black?  What's the end effect you're going for?  Would something like the 
 coloroverlay graphic effect be a workable option?
 
 Regards,
 
 Scott Rossi
 Creative Director
 Tactile Media, UX Design
 
 
 On Jul 21, 2012, at 10:06 PM, J. Landman Gay jac...@hyperactivesw.com 
 wrote:
 
 On 7/21/12 11:06 PM, Randy Hengst wrote:
 
 The Imaging Blends do work with accelerated rendering set to true…
 But, none of them will turn the image black… or dark gray… these
 blends are influenced by the background color.
 
 Is it to be expected that acceleratedRendering will disable the
 Structural Blends? Or, is that a bug?
 
 I just posted the restrictions in another message, but yes, it looks like 
 it's expected. You might have better luck using graphics effects and setting 
 an opaque black color overlay. Or maybe Scott Rossi knows a better way to do 
 it.
 
 -- 
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.com
 
 
 ___
 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


___
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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread Randy Hengst
Hi Klaus and All,

I'm just now trying to get my head around accelerated rendering.

I don't have access to Windows, so can't comment specifically on what Klaus 
discovered.

However, I can confirm a problem with INK and accelerated rendering on LC5.5.1 
when running the app on iOS simulator or device.

I noticed this when updating an app where images are dragged around…that's why 
I was using accelerated render….

I've set the INK on the draggable images to clear when the image is first 
shown to the user… with accelerated rendering set to false, the image is 
black…. with accelerated rendering set to true, the image seems to be stuck in 
its original color...

In other words, if I change the INK state to clear while accelerated rendering 
is true, nothing happens… but, the image changes when I set accelerated 
rendering to false… 

I can tell by using the Inspector that the INK of the image has been set to 
clear….

It's easy to duplicate this problem, but I'd be happy to send out a small stack.

Interestingly, in my main project… setting INK to clear still works on my Mac… 
but, the small demo stack doesn't work.

Anyone have a work-around for this INK bump?

be well,
randy
-
On May 3, 2012, at 2:17 PM, Klaus on-rev wrote:

 Hi all,
 
 Am 03.05.2012 um 20:23 schrieb Klaus on-rev:
 
 Hi freinds
 
 I just found an evil bug on the Mac :-/
 LiveCode 5.02
 
 When you set the acceleratedrendering of this stack to true
 all objects with their INK set to NOOP will become visible again.
 
 This does not happen on Windows.
 
 Can someone please confirm this, before I bug report?
 Does this also happen in LC 5.5x?
 
 Bug #10202:
 http://quality.runrev.com/show_bug.cgi?id=10202
 
 
 Best
 
 Klaus
 
 --
 Klaus Major
 http://www.major-k.de
 kl...@major.on-rev.com
 
 
 ___
 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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread J. Landman Gay

On 7/21/12 5:37 PM, Randy Hengst wrote:


I've set the INK on the draggable images to clear when the image is
first shown to the user… with accelerated rendering set to false, the
image is black…. with accelerated rendering set to true, the image
seems to be stuck in its original color...

In other words, if I change the INK state to clear while accelerated
rendering is true, nothing happens… but, the image changes when I set
accelerated rendering to false…


This, along with Klaus' NOOP problem, is probably because the old inks 
were deprecated as of LiveCode version 5.0. They are now unsupported and 
may or may not work. The ink entry in the dictionary lists the 
supported alternatives.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread Randy Hengst
Hi Jacque,

Thanks for the scoop. That's good to know… To be honest, since they are still 
listed under the blend options, I didn't think about them being discontinued.

As I mentioned, clear still turns the image black (like I want) in my 
original app … I didn't notice the problem until I added the 
acceleratedRendering… and then, the problem only showed itself in the simulator 
and device… not in the IDE.

So, I explored the two other INK options… Structural Blends and Imaging Blends.

Two of the Structural Blends turn the image black… like I want… blendXor and 
blendDstOut 
But, the structural blends do *not* work when acceleratedRendering is set to 
true.

The Imaging Blends do work with accelerated rendering set to true… 
But, none of them will turn the image black… or dark gray… these blends are 
influenced by the background color.

Is it to be expected that acceleratedRendering will disable the Structural 
Blends? Or, is that a bug?

be well,
randy
---
On Jul 21, 2012, at 10:12 PM, J. Landman Gay wrote:

 On 7/21/12 5:37 PM, Randy Hengst wrote:
 
 I've set the INK on the draggable images to clear when the image is
 first shown to the user… with accelerated rendering set to false, the
 image is black…. with accelerated rendering set to true, the image
 seems to be stuck in its original color...
 
 In other words, if I change the INK state to clear while accelerated
 rendering is true, nothing happens… but, the image changes when I set
 accelerated rendering to false…
 
 This, along with Klaus' NOOP problem, is probably because the old inks were 
 deprecated as of LiveCode version 5.0. They are now unsupported and may or 
 may not work. The ink entry in the dictionary lists the supported 
 alternatives.
 
 -- 
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.com
 
 
 ___
 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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread Scott Rossi
Randy:

I don't have LiveCode in front of me but I'm pretty sure the docs list several 
of the ink limitations of acceleratedRendering there.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design



On Jul 21, 2012, at 9:06 PM, Randy Hengst iowahen...@mac.com wrote:

 Hi Jacque,
 
 Thanks for the scoop. That's good to know… To be honest, since they are still 
 listed under the blend options, I didn't think about them being discontinued.
 
 As I mentioned, clear still turns the image black (like I want) in my 
 original app … I didn't notice the problem until I added the 
 acceleratedRendering… and then, the problem only showed itself in the 
 simulator and device… not in the IDE.
 
 So, I explored the two other INK options… Structural Blends and Imaging 
 Blends.
 
 Two of the Structural Blends turn the image black… like I want… blendXor 
 and blendDstOut 
 But, the structural blends do *not* work when acceleratedRendering is set to 
 true.
 
 The Imaging Blends do work with accelerated rendering set to true… 
 But, none of them will turn the image black… or dark gray… these blends are 
 influenced by the background color.
 
 Is it to be expected that acceleratedRendering will disable the Structural 
 Blends? Or, is that a bug?
 
 be well,
 randy
 ---
 On Jul 21, 2012, at 10:12 PM, J. Landman Gay wrote:
 
 On 7/21/12 5:37 PM, Randy Hengst wrote:
 
 I've set the INK on the draggable images to clear when the image is
 first shown to the user… with accelerated rendering set to false, the
 image is black…. with accelerated rendering set to true, the image
 seems to be stuck in its original color...
 
 In other words, if I change the INK state to clear while accelerated
 rendering is true, nothing happens… but, the image changes when I set
 accelerated rendering to false…
 
 This, along with Klaus' NOOP problem, is probably because the old inks were 
 deprecated as of LiveCode version 5.0. They are now unsupported and may or 
 may not work. The ink entry in the dictionary lists the supported 
 alternatives.
 
 -- 
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.com
 
 
 ___
 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
 

___
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

Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread J. Landman Gay

On 7/21/12 11:34 PM, Scott Rossi wrote:


I don't have LiveCode in front of me but I'm pretty sure the docs
list several of the ink limitations of acceleratedRendering there.


I just found it in the 5.02 release notes:

Accelerated rendering comes with some restrictions:
• Bitmap effects which use the multiply and color dodge blend modes will 
not work correctly on top-level objects.
• Only 'blendSrcOver' and the image processing blend inks will work on 
top-level objects.
• 'opengl' mode does not support any inks apart from blendSrcOver on 
top-level objects.
• Using an ink other than 'blendSrcOver' on a top-level object will 
implicitly make it use 'dynamic' layerMode


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread J. Landman Gay

On 7/21/12 11:06 PM, Randy Hengst wrote:


The Imaging Blends do work with accelerated rendering set to true…
But, none of them will turn the image black… or dark gray… these
blends are influenced by the background color.

Is it to be expected that acceleratedRendering will disable the
Structural Blends? Or, is that a bug?


I just posted the restrictions in another message, but yes, it looks 
like it's expected. You might have better luck using graphics effects 
and setting an opaque black color overlay. Or maybe Scott Rossi knows a 
better way to do it.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread Scott Rossi
Those are them.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design

On Jul 21, 2012, at 10:01 PM, J. Landman Gay jac...@hyperactivesw.com wrote:

 On 7/21/12 11:34 PM, Scott Rossi wrote:
 
 I don't have LiveCode in front of me but I'm pretty sure the docs
 list several of the ink limitations of acceleratedRendering there.
 
 I just found it in the 5.02 release notes:
 
 Accelerated rendering comes with some restrictions:
 • Bitmap effects which use the multiply and color dodge blend modes will not 
 work correctly on top-level objects.
 • Only 'blendSrcOver' and the image processing blend inks will work on 
 top-level objects.
 • 'opengl' mode does not support any inks apart from blendSrcOver on 
 top-level objects.
 • Using an ink other than 'blendSrcOver' on a top-level object will 
 implicitly make it use 'dynamic' layerMode
 
 -- 
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.com
 
 
 ___
 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

Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-07-21 Thread Scott Rossi
The first question to Randy would be, why do you want to change the image to 
black?  What's the end effect you're going for?  Would something like the 
coloroverlay graphic effect be a workable option?

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


On Jul 21, 2012, at 10:06 PM, J. Landman Gay jac...@hyperactivesw.com wrote:

 On 7/21/12 11:06 PM, Randy Hengst wrote:
 
 The Imaging Blends do work with accelerated rendering set to true…
 But, none of them will turn the image black… or dark gray… these
 blends are influenced by the background color.
 
 Is it to be expected that acceleratedRendering will disable the
 Structural Blends? Or, is that a bug?
 
 I just posted the restrictions in another message, but yes, it looks like 
 it's expected. You might have better luck using graphics effects and setting 
 an opaque black color overlay. Or maybe Scott Rossi knows a better way to do 
 it.
 
 -- 
 Jacqueline Landman Gay | jac...@hyperactivesw.com
 HyperActive Software   | http://www.hyperactivesw.com
 
 
 ___
 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

Re: acceleratedRendering is my friend

2012-06-28 Thread Matthias Rebbe
Hi Tom,

thanks for sharing this with us.

 . Immediately before moving an object turn on dynamic or when scrolling a 
 group turn on scrolling
 once moving the scroll or object has already been cached and drawn so these 
 are no longer necessary. No need to turn these things on and leave them on 
 because they are not needed and the result is that things will actually 
 slow down.

What do you mean with that? Lets say i have a card, where several obejcts in a 
group shall be scrolled. At the moment i do the complete scroller stufff 
(creating the scroller and so on) in the open card handler.  Is this the right 
way. Or what do you mean with immediately before moving/scrolling?

Regards,

Matthias


Am 28.06.2012 um 06:31 schrieb Thomas McGrath III:

 From what Mark said the preopencard is the place to do it and I have not seen 
 any flashing in 5.5.1
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 On Jun 27, 2012, at 2:27 PM, Chris Sheffield wrote:
 
 Tom,
 
 Thanks for the info. Very useful.
 
 I haven't actually tried any of this yet, but is there still a problem where 
 the screen flashes when toggling acceleratedRendering on/off in preOpenCard 
 and closeCard? I was seeing this a couple months back, so I'm curious if 
 that still exists. I haven't tried it with LC 5.5.1. It may only happen when 
 moving from card to card using a visual effect.
 
 Thanks,
 Chris
 
 
 On Jun 27, 2012, at 9:57 AM, Thomas McGrath III mcgra...@mac.com wrote:
 
 After sitting with Mark W. for an hour over lunch yesterday I was able to 
 both understand the role of acceleratedRendering and the best usage of it. 
 It turns out that the order of when these commands are used is of utmost 
 importance. I have been rewriting my code and have an instant increase in 
 responsiveness in my scrolling groups. 
 
 In a nut shell:
 1. on preopenCard - set the acceleratedRendering of this stack to true 
 (only on cards that ave scrolling or dynamic groups/objects
 2. Immediately before moving an object turn on dynamic or when scrolling a 
 group turn on scrolling
 once moving the scroll or object has already been cached and drawn so these 
 are no longer necessary. No need to turn these things on and leave them on 
 because they are not needed and the result is that things will actually 
 slow down.
 3. Immediately after moving or scrolling an object turn off the scrolling 
 or dynamic settings
 4. on closeCard - set the acceleratedRendering of this stack to false (turn 
 it off since it is not needed)
 
 
 This simple approach seems so obvious now and has immediate results.
 
 The other thing that Ben and Mark showed me was that having large scrolling 
 groups of object is much much much faster than using visual effects and 
 switching cards.
 
 More as I grok this….
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 
 ___
 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
 
 
 ___
 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


Re: acceleratedRendering is my friend

2012-06-28 Thread Thomas McGrath III
Matthias,

It was my understanding that for scrolling you would create the scroller at the 
preOpenCard after you set the acceleratedRendering and the layerMode:

on preOpenCard
   set the acceleratedRendering of this stack to true
set the layerMode of group OptionGroups of card Settings1 to scrolling

… create scroller here
  end preOpenCard   



-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgr...@comcast.net

On Jun 28, 2012, at 3:17 AM, Matthias Rebbe wrote:

 Hi Tom,
 
 thanks for sharing this with us.
 
 . Immediately before moving an object turn on dynamic or when scrolling a 
 group turn on scrolling
 once moving the scroll or object has already been cached and drawn so 
 these are no longer necessary. No need to turn these things on and leave 
 them on because they are not needed and the result is that things will 
 actually slow down.
 
 What do you mean with that? Lets say i have a card, where several obejcts in 
 a group shall be scrolled. At the moment i do the complete scroller stufff 
 (creating the scroller and so on) in the open card handler.  Is this the 
 right way. Or what do you mean with immediately before moving/scrolling?
 
 Regards
 
 Matthias
 
 
 Am 28.06.2012 um 06:31 schrieb Thomas McGrath III:
 
 From what Mark said the preopencard is the place to do it and I have not 
 seen any flashing in 5.5.1
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 On Jun 27, 2012, at 2:27 PM, Chris Sheffield wrote:
 
 Tom,
 
 Thanks for the info. Very useful.
 
 I haven't actually tried any of this yet, but is there still a problem 
 where the screen flashes when toggling acceleratedRendering on/off in 
 preOpenCard and closeCard? I was seeing this a couple months back, so I'm 
 curious if that still exists. I haven't tried it with LC 5.5.1. It may only 
 happen when moving from card to card using a visual effect.
 
 Thanks,
 Chris
 
 
 On Jun 27, 2012, at 9:57 AM, Thomas McGrath III mcgra...@mac.com wrote:
 
 After sitting with Mark W. for an hour over lunch yesterday I was able to 
 both understand the role of acceleratedRendering and the best usage of it. 
 It turns out that the order of when these commands are used is of utmost 
 importance. I have been rewriting my code and have an instant increase in 
 responsiveness in my scrolling groups. 
 
 In a nut shell:
 1. on preopenCard - set the acceleratedRendering of this stack to true 
 (only on cards that ave scrolling or dynamic groups/objects
 2. Immediately before moving an object turn on dynamic or when scrolling a 
 group turn on scrolling
 once moving the scroll or object has already been cached and drawn so 
 these are no longer necessary. No need to turn these things on and leave 
 them on because they are not needed and the result is that things will 
 actually slow down.
 3. Immediately after moving or scrolling an object turn off the scrolling 
 or dynamic settings
 4. on closeCard - set the acceleratedRendering of this stack to false 
 (turn it off since it is not needed)
 
 
 This simple approach seems so obvious now and has immediate results.
 
 The other thing that Ben and Mark showed me was that having large 
 scrolling groups of object is much much much faster than using visual 
 effects and switching cards.
 
 More as I grok this….
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 
 ___
 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
 
 
 ___
 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


___
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


Re: acceleratedRendering is my friend

2012-06-28 Thread Chris Sheffield
I just checked this in LC 5.5.1 to make sure, and there is still a bug that 
exists where the screen will flash when toggling acceleratedRendering if you're 
moving from card to card using a visual effect. A ticket has already been 
submitted. The way around it is to set the property in a handler, and then 
send that handler.

Just thought I'd share in case anyone else runs into this. :-)

Chris


--
Chris Sheffield
Read Naturally, Inc.
www.readnaturally.com



On Jun 28, 2012, at 2:11 PM, Chipp Walters ch...@chipp.com wrote:

 Just wanted to share a couple other key points Tom and I discussed after
 lunch today:
 
 The object of the control you are setting the dynamic or scrolling property
 of MUST be a toplevel control. IOW, the *parent* of the control MUST be the
 card. So, you can't accelerate objects within groups, but rather the group
 itself. Consequently, you don't set properties of any objects in groups.
 You can use the property inspector for the control and it will stick and
 you don't need to set it again.
 
 Use the preOpenCard handler to manage acceleration (turn on and then off on
 closeCard) on a per card basis, so as to conserve memory. You don't want a
 lot of images cached from different cards clogging up memory!
 
 As mentioned, the three property values are static, scrolling and dynamic.
 Everything by default is static. Sprites or any items who are not hidden by
 the rect of a group are dynamic. Groups and included controls are scrolling
 (just set the group, not the controls within the group).
 
 HTH
 
 On Thursday, June 28, 2012, Matthias Rebbe wrote:
 
 Hi Tom,
 
 thanks for sharing this with us.
 
 . Immediately before moving an object turn on dynamic or when
 scrolling a group turn on scrolling
 once moving the scroll or object has already been cached and drawn so
 these are no longer necessary. No need to turn these things on and leave
 them on because they are not needed and the result is that things will
 actually slow down.
 
 What do you mean with that? Lets say i have a card, where several obejcts
 in a group shall be scrolled. At the moment i do the complete scroller
 stufff (creating the scroller and so on) in the open card handler.  Is this
 the right way. Or what do you mean with immediately before
 moving/scrolling?
 
 Regards,
 
 Matthias
 
 
 Am 28.06.2012 um 06:31 schrieb Thomas McGrath III:
 
 From what Mark said the preopencard is the place to do it and I have not
 seen any flashing in 5.5.1
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 On Jun 27, 2012, at 2:27 PM, Chris Sheffield wrote:
 
 Tom,
 
 Thanks for the info. Very useful.
 
 I haven't actually tried any of this yet, but is there still a problem
 where the screen flashes when toggling acceleratedRendering on/off in
 preOpenCard and closeCard? I was seeing this a couple months back, so I'm
 curious if that still exists. I haven't tried it with LC 5.5.1. It may only
 happen when moving from card to card using a visual effect.
 
 Thanks,
 Chris
 
 
 On Jun 27, 2012, at 9:57 AM, Thomas McGrath III mcgra...@mac.com
 wrote:
 
 After sitting with Mark W. for an hour over lunch yesterday I was able
 to both understand the role of acceleratedRendering and the best usage of
 it. It turns out that the order of when these commands are used is of
 utmost importance. I have been rewriting my code and have an instant
 increase in responsiveness in my scrolling groups.
 
 In a nut shell:
 1. on preopenCard - set the acceleratedRendering of this stack to true
 (only on cards that ave scrolling or dynamic groups/objects
 2. Immediately before moving an object turn on dynamic or when
 scrolling a group turn on scrolling
 once moving the scroll or object has already been cached and drawn so
 these are no longer necessary. No need to turn these things on and leave
 them on because they are not needed and the result is that things will
 actually slow down.
 3. Immediately after moving or scrolling an object turn off the
 scrolling or dynamic settings
 4. on closeCard - set the acceleratedRendering of this stack to false
 (turn it off since it is not needed)
 
 
 This simple approach seems so obvious now and has immediate results.
 
 The other thing that Ben and Mark showed me was that having large
 scrolling groups of object is much much much faster than using visual
 effects and switching cards.
 
 More as I grok this….
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 
 ___
 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:
 

Re: acceleratedRendering is my friend

2012-06-27 Thread Chris Sheffield
Tom,

Thanks for the info. Very useful.

I haven't actually tried any of this yet, but is there still a problem where 
the screen flashes when toggling acceleratedRendering on/off in preOpenCard and 
closeCard? I was seeing this a couple months back, so I'm curious if that still 
exists. I haven't tried it with LC 5.5.1. It may only happen when moving from 
card to card using a visual effect.

Thanks,
Chris


On Jun 27, 2012, at 9:57 AM, Thomas McGrath III mcgra...@mac.com wrote:

 After sitting with Mark W. for an hour over lunch yesterday I was able to 
 both understand the role of acceleratedRendering and the best usage of it. It 
 turns out that the order of when these commands are used is of utmost 
 importance. I have been rewriting my code and have an instant increase in 
 responsiveness in my scrolling groups. 
 
 In a nut shell:
 1. on preopenCard - set the acceleratedRendering of this stack to true (only 
 on cards that ave scrolling or dynamic groups/objects
 2. Immediately before moving an object turn on dynamic or when scrolling a 
 group turn on scrolling
 once moving the scroll or object has already been cached and drawn so these 
 are no longer necessary. No need to turn these things on and leave them on 
 because they are not needed and the result is that things will actually slow 
 down.
 3. Immediately after moving or scrolling an object turn off the scrolling or 
 dynamic settings
 4. on closeCard - set the acceleratedRendering of this stack to false (turn 
 it off since it is not needed)
 
 
 This simple approach seems so obvious now and has immediate results.
 
 The other thing that Ben and Mark showed me was that having large scrolling 
 groups of object is much much much faster than using visual effects and 
 switching cards.
 
 More as I grok this….
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 
 ___
 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


Re: acceleratedRendering is my friend

2012-06-27 Thread Thomas McGrath III
From what Mark said the preopencard is the place to do it and I have not seen 
any flashing in 5.5.1

-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgr...@comcast.net

On Jun 27, 2012, at 2:27 PM, Chris Sheffield wrote:

 Tom,
 
 Thanks for the info. Very useful.
 
 I haven't actually tried any of this yet, but is there still a problem where 
 the screen flashes when toggling acceleratedRendering on/off in preOpenCard 
 and closeCard? I was seeing this a couple months back, so I'm curious if that 
 still exists. I haven't tried it with LC 5.5.1. It may only happen when 
 moving from card to card using a visual effect.
 
 Thanks,
 Chris
 
 
 On Jun 27, 2012, at 9:57 AM, Thomas McGrath III mcgra...@mac.com wrote:
 
 After sitting with Mark W. for an hour over lunch yesterday I was able to 
 both understand the role of acceleratedRendering and the best usage of it. 
 It turns out that the order of when these commands are used is of utmost 
 importance. I have been rewriting my code and have an instant increase in 
 responsiveness in my scrolling groups. 
 
 In a nut shell:
 1. on preopenCard - set the acceleratedRendering of this stack to true (only 
 on cards that ave scrolling or dynamic groups/objects
 2. Immediately before moving an object turn on dynamic or when scrolling a 
 group turn on scrolling
 once moving the scroll or object has already been cached and drawn so these 
 are no longer necessary. No need to turn these things on and leave them on 
 because they are not needed and the result is that things will actually slow 
 down.
 3. Immediately after moving or scrolling an object turn off the scrolling or 
 dynamic settings
 4. on closeCard - set the acceleratedRendering of this stack to false (turn 
 it off since it is not needed)
 
 
 This simple approach seems so obvious now and has immediate results.
 
 The other thing that Ben and Mark showed me was that having large scrolling 
 groups of object is much much much faster than using visual effects and 
 switching cards.
 
 More as I grok this….
 
 -- Tom McGrath III
 http://lazyriver.on-rev.com
 3mcgr...@comcast.net
 
 
 ___
 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


___
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


Re: acceleratedrendering = true and ink = NOOP don't cooperate :-/

2012-05-03 Thread Klaus on-rev
Hi all,

Am 03.05.2012 um 20:23 schrieb Klaus on-rev:

 Hi freinds
 
 I just found an evil bug on the Mac :-/
 LiveCode 5.02
 
 When you set the acceleratedrendering of this stack to true
 all objects with their INK set to NOOP will become visible again.
 
 This does not happen on Windows.
 
 Can someone please confirm this, before I bug report?
 Does this also happen in LC 5.5x?

Bug #10202:
http://quality.runrev.com/show_bug.cgi?id=10202


Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major.on-rev.com


___
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