Yes, that page refers to the new feature coming in the 9.5 release (already
available in DP1).
Thanks,
Brian
On Jun 1, 2019, 4:21 AM -0400, Simon Knight via use-livecode
, wrote:
> I have only just resubscribed to the mailing list so may have missed some
> conversations on this subject, so I ap
I have only just resubscribed to the mailing list so may have missed some
conversations on this subject, so I apologise for hijacking this thread.
I am interested in this new to me layer mode of “container” being discussed
here. I see that it is also mentioned in “This week in Livecode” :
Monte Goulding wrote:
At some point in the future we may support applying transformations to
dynamic layerMode objects (changing size and perhaps location) which would mean
Ken Burn effect would be done by the GPU. I suspect that’s a fair way off and
would definitely involve some serious Ma
anged with respect to doing Ken Burn effect with large
> image, or a parallax effect with images placed on top of each other, or far
> that matter, moving an animated gif across the screen. Setting these to a
> dynamic layerMode, with acceleratedRendering sent to true is still "ver
far that
matter, moving an animated gif across the screen. Setting these to a dynamic
layerMode, with acceleratedRendering sent to true is still "very expensive"
and will block the engine.
Assuming we continue to use Animated Engine (since no better tool has arrived)
1) we can chang
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 a
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
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 t
://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
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
>
> 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 ou
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
ender 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 th
<
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 blac
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
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
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
pro
> @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
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 me
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
-livecode" wrote:
Yes I just patched it https://github.com/livecode/livecode/pull/6620
<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…
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
<https://github.com/livecode/livecode/pull/6620>
> FWIW... acceleratedRendering in causing trouble on Android, 9.0.1. RC 1.
>
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
Hi All,
Given what we’re heard about iOS12 problems with LC apps… and the suggestion
that setting acceleratedRendering to true in preOpenStack “solves” that issue
with iOS12, I’ve been messing around with acceleratedRendering for the current
LC project I’m developing for iOS. I have not used
What Jacque said;
Originally you had built the standalone with LC 9.0.1 rc1 (and installed it
in the device), so its manifest had targetSDKversion=26.
Then you built a new one with LC 9.0.0, so it had its targetSDKversion
equal to the minSDKversion, as specified in the standalone settings, and
pro
It could be because 9.0.1 sets the target version in the manifest to 26
and 9.0 sets it to the same version as the one you select in the
dropdown menu in standalone settings. If you've truly removed the old
app completely I wouldn't think it would matter, but apparently Android
stores some reco
Hi Dan
> >> >
> >> > A little update.
> >> >
> >> > The bug report is here:
> >> > https://quality.livecode.com/show_bug.cgi?id=21434 <
> >> https://quality.livecode.
PR for the fix is here:
>> > https://github.com/livecode/livecode/pull/6610 <
>> https://github.com/livecode/livecode/pull/6610>
>> >
>> > Cheers
>> >
>> > Monte
>> >
>> &g
livecode.com/show_bug.cgi?id=21434 <
>> https://quality.livecode.com/show_bug.cgi?id=21434>
>> >
>> > The PR for the fix is here:
>> > https://github.com/livecode/livecode/pull/6610 <
>> https://github.com/livecode/livecode/pull/6
ality.livecode.com/show_bug.cgi?id=21434 <
> https://quality.livecode.com/show_bug.cgi?id=21434>
> >
> > The PR for the fix is here:
> > https://github.com/livecode/livecode/pull/6610 <
> https://github.com/livecode/livecode/pull/6610>
> >
> > Ch
Jul 2018, at 9:54 am, Monte Goulding via use-livecode wrote:
>
> Hi Dan
>
> This looks like a regression from the large number of
acceleratedRendering related patches that went into 9.0.1 rc 1. I am looking into
it as it will
at 9:54 am, Monte Goulding via use-livecode
wrote:
>
> Hi Dan
>
> This looks like a regression from the large number of
acceleratedRendering related patches that went into 9.0.1 rc 1. I am looking
into it as it will be a blocker for 9.0.1-rc-2.
; On 20 Jul 2018, at 9:54 am, Monte Goulding via use-livecode
wrote:
>
> Hi Dan
>
> This looks like a regression from the large number of
acceleratedRendering related patches that went into 9.0.1 rc 1. I am looking
into it as it will be a blocker for 9.0.1-rc-2.
heers
Monte
> On 20 Jul 2018, at 9:54 am, Monte Goulding via use-livecode
> wrote:
>
> Hi Dan
>
> This looks like a regression from the large number of acceleratedRendering
> related patches that went into 9.0.1 rc 1. I am looking into it as it will be
> a blocker fo
Hi Dan
This looks like a regression from the large number of acceleratedRendering
related patches that went into 9.0.1 rc 1. I am looking into it as it will be a
blocker for 9.0.1-rc-2.
Cheers
Monte
> On 20 Jul 2018, at 4:13 am, Dan Friedman via use-livecode
> wrote:
>
> Hello
Hello!
Using LC 9.0.1 (rc1), on android only, if I have acceleratedRendering on, the
effect is not applied when doing this:
lock screen for visual effect
//do something
unlock screen with visual effect wipe left //any effect fails
However, if acceleratedRendering is off, the visual effect is
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
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 card
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 layer
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 w
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 ac
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, *
gle 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 acc
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 accele
On 9/23/17 2:27 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
when we issue "wait 200 milliseconds with messages" does the engine send idle to the
card? i.e now the phone OS has time to "catch up" ??
Basically. The idle message is sent regularly whenever no other handlers
are runnin
consumed every time we want use it… perhaps
what works is
1) finish all inits
2) set acceleratedRendering to true at the same time we create our mobile
scroller
3) set it to false the same time we delete all our mobile controls
if this actually works, then we can just
I had these exact same issues: black screen if acceleratedRendering was
enabled on Android at startup. I found that if I set the acceleratedRendering
to true after ALL startup items were complete (preOpenCard, preOpenStack,
openCard, openStack, and whatever else you’re doing at launch
x27;s kind of odd though, because the wait occurs before
acceleratedRendering is set. I'm not sure how a prior wait could affect
a command that hasn't happened yet.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Plea
It's kind of odd though, because the wait occurs before
acceleratedRendering is set. I'm not sure how a prior wait could affect
a command that hasn't happened yet.
On 9/22/17 2:20 PM, panagiotis merakos via use-livecode wrote:
Hi Jacque,
Thanks for checking. Yes, it seems tha
just tested Swami's app on my Pixel running Oreo (Android 8) and
> acceleratedRendering seems to be working okay. There is a preOpenStack
> handler in the stack script:
>
> on preopenstack
>wait 100 milliseconds with messages
>set the fullScreenMode of this stack to &quo
Panos: I just tested Swami's app on my Pixel running Oreo (Android 8)
and acceleratedRendering seems to be working okay. There is a
preOpenStack handler in the stack script:
on preopenstack
wait 100 milliseconds with messages
set the fullScreenMode of this stack to "ShowAll&q
Jonathan
Right -- Excellent. Thanks. I missed that before.. and yes I had this same
experience and asked myself "What happened?"
OK I'll have to go back and look that up, well work doing. Agreed. I guess was
testing so much in Android, I forgot that apple actually closes. Would be nice
to exp
I have a Pixel that was just updated to Oreo (Android 8) and running
Swami's app works okay. That's the one app I happen to have installed
that uses acceleratedRendering quite a bit.
He's made some changes recently that turns it on and off after the card
has already loaded, bu
Hi Jacque,
Are you on Android 7 or 8? It does not work for me if I set the
acceleratedRendering in preopenstack or openstack. I did not check with
opencard/preopencard.
On Wed, Sep 20, 2017 at 10:13 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Does i
Does it work if you set acceleratedRendering in preOpenStack or
preOpenCard? It seems to work okay for me that way.
On 9/20/17 5:21 AM, panagiotis merakos via use-livecode wrote:
Hi folks,
Today I came across this issue, affecting Android 7 and Android 8:
on openStack
set the
Hi folks,
Today I came across this issue, affecting Android 7 and Android 8:
on openStack
set the acceleratedRendering of this stack to true
end openStack
This results in black screen when the app starts.
Workaround:
on openStack
send "fixit" to me in 0 millisec
end openStack
Sorry - that was meant to go direct, not via the list.
My deepest apologies.
Alex
On 19/09/2017 23:36, Alex Tweedly wrote:
On 19/09/2017 18:46, Sannyasin Brahmanathaswami via use-livecode wrote:
Accolades don't help me, I prefer Ruthless Critique (some of my
brothers here have already issu
On 19/09/2017 18:46, Sannyasin Brahmanathaswami via use-livecode wrote:
Accolades don't help me, I prefer Ruthless Critique (some of my brothers here
have already issued scathing reviews
good line :-)
Picky about punctuation
in "App News", 10Aug2017, it has
button (right on iOS le
I was in the app and went to the section where it profiled your community
members with a browser widget, pulled from your website, I think. When I got
out and got back in, I had to navigate to the same place. With Ralph's plist
hack, on iOS, it will sleep rather than close. That way, when you ge
Jonathan
I'm not sure exactly what this "stay in sleep mode" gets us… but yes, it's an
interesting option.
if we use this hack, would the audio continue to play when the user goes out ?
Why are you recommending it?
---
"imagery"
Yes, with 400,000 still images on our in-house server and 3
uilt with 8.1.7-rc-1
whenever we use the home button or app switcher in the app.
if the stack we are leaving from has acceleratedRendering set to true (all
most all stacks) when we return to the app from going out via HOME or App
switcher it crashes on Android.
For details:
see bug 204
tton or app switcher in the app.
>
> if the stack we are leaving from has acceleratedRendering set to true (all
> most all stacks) when we return to the app from going out via HOME or App
> switcher it crashes on Android.
>
> For details:
>
> see bug 20419
>
>
re leaving from has acceleratedRendering set to true (all most
all stacks) when we return to the app from going out via HOME or App switcher
it crashes on Android.
For details:
see bug 20419
Brahmanathaswami
___
use-livecode mailing list
us
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
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 repor
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
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
a 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?
>>
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
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
> On Sep 4, 2015, at 12:30, Dan Friedman wrote:
>
> So, the screen must not be locked, and acceleratedRendering must be off.
> Not sure if you call that a bug or not... but it's working. Hope I don't
> have issues when I try it on Android.
or…
export s
Mark,
Ok... I found the combination that works. This assumes you have opened a stack
and acceleratedRendering is enabled:
THIS FAILS (produces a grey image):
lock screen
export snapshot from rect (the rect of this card) to pictVariable as PNG
//do some stuff
unlock screen
THIS FAILS:
export
Mark, Thanks for the help but 'the rect of this card' produced the same
result a grey image. Any other thoughts?
-Dan
> Try doing from rect ... of this card. I think the form you are using is doing
> a screen buffer grab, which doesn't play so well with the OpenGL surface
> accelerated
uffer.
Mark
Sent from my iPhone
> On 4 Sep 2015, at 18:29, Dan Friedman wrote:
>
> On either the iPhone simulator or an actual device, if acceleratedRendering
> is enabled and I do:
>
>export snapshot from rect (the rect of this card) to pictVariable as PNG
>
> I get a
On either the iPhone simulator or an actual device, if acceleratedRendering is
enabled and I do:
export snapshot from rect (the rect of this card) to pictVariable as PNG
I get a solid grey image. If I never enable acceleratedRendering, then the
image comes out fine. It seems that
I have a scrolling field. The list has every other line's backgroundcolor
set to (100,100,100)/(125,125,125). The background image is visible behind
the field. This was dog slow on some mobile devices. I turned on
acceleratedRendering and the field scrolls is as fast as any native coded
app.
el object will
implicitly make it use 'dynamic' layerMode
Regards,
Scott Rossi
Creative Director
Tactile Media, UX Design
Recently, Michael Kristensen wrote:
> Hi there
>
> If I use acceleratedRendering, the blendmode "transparent" set on images is
> not
Hi there
If I use acceleratedRendering, the blendmode "transparent" set on images is not
working.
That is, white areas are not transparent, but opaque/white.
OSX 10.6.8 Livecode 5.5.1
Thanks
Michael
___
use-livecode mailing list
us
rote:
>
>> 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.
>>
ound 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 effect
t; 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-leve
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
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 eff
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 wrote:
> Hi Jacque,
>
otice 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… "ble
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 ot
e 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
>>
>&g
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
ked 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 han
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 ha
;
> > -- 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&#x
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
t; 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 t
t; 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 wit
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.
On Wed, Jun 27, 2012 at 11:57 AM, Thomas McGrath III 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
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
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 agai
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
quot;pop-up" group is displayed that
>> includes a blended button that covers the background in order to
>> disallow interacting with anything else until the "pop-up" is
>> dismissed. When this pop-up is displayed, I'm setting
>> acceleratedRendering to fa
1 - 100 of 102 matches
Mail list logo
