revGeometry

This forum is a working group for community contributors to the LiveCode IDE included in the main LiveCode distribution.

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller

Post Reply
malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

revGeometry

Post by malte » Sat Jun 01, 2013 12:43 pm

I was working out why a resizing script took forever to complete recently. I already posted under feature requests, however, I would like to also bring it up here. Right now a major Problem in the IDE is working with stacks with a larger amount of controls on the card. The problem appears to be that revCacheGeometry is called during the resize (have not drilled in deep enough to see what message triggers it). The main problem is a repeat with i=1 to the number of controls loop in there which takes quite a while to finish when there is a large number of controls (think a couple of datagrids). There are a few ways to tackle this (especially with some of the engine changes).

So I propose:
- to optimize the script in there for future engines (repeat for each control)
- to find a way to only put the geometry script in the back, once you start using revGeometry

Where the latter should also apply to a more optimized version of revGeometry (or an replacement thereof). I suspect there are quite a few scripts lurking in back and front that could use some optimization, however revGeometry is one of those that bit me most recently.

Thoughts?

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 1893
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria
Contact:

Re: revGeometry

Post by richmond62 » Sat Jun 01, 2013 9:24 pm

Personally every time I've messed around with the Geometry Manager I've ended up making a mess.

I suspect that 50% of the reason for the mess is me; but the other 50% must lie with Livecode.

I do believe that, iff, Livecode is to be really capable of resizing everything to fit the Geomtry Manager
or whatever replaces it has to be remade in a way that is considerably easier to use.

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: revGeometry

Post by malte » Sat Jun 01, 2013 10:54 pm

I'm in the same boat. I do not even touch the GM with a very long stick. The problem at the moment is that it lurks in the backscripts, stealing cycles. One does not notice with few controls on the card, however it gets worse with increasing numbers of controls getting to a point where a resizestack handler can not not finish its duty and the engine gets stuck for no obvious reason (you need to command period out of it). The reason only becomes apparent, when you put true into gRevDevelopment. Then you end up in the revCacheGeometry handler, even though the stack does not use geometry at all.

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: revGeometry

Post by phaworth » Mon Jun 03, 2013 6:29 pm

I'm sure there are a lot of scripts out there that implement resizing in a cleaner way than the GM. I have one that either positions/resizes a control relative to the right and bottom edge of the stack, with the "instructions" stored in a custom property of each control.

Don't remember offhand but was a replacement GM one of the goals/stretch goals of the FOSS project?

DaltonCalford
Posts: 22
Joined: Fri May 06, 2011 7:33 pm

Re: revGeometry

Post by DaltonCalford » Fri Jun 21, 2013 4:06 pm

From other languages I have used, their approach was that a visual control had a "parent" (think group)
If something was told to resize/redraw, it also iterated threw it's child list, sending them a resize/redraw command.
If a parent was not on screen at the time, or if it was invisible or, if it just did not need to resize, then it would never get the resize/redraw instruction.
This eliminated the need to iterate threw every screen object on every redraw.
Also, the geometry was always in regards to the parent object - ie "align left", "align top" or any one of many different options. It made control layout very simple.

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: revGeometry

Post by malte » Sun Sep 15, 2013 12:52 pm

I must say this dradded thing is getting more and more on my nerves...

Is the mothership snooping in this forum? I would really like to be able to turn off the GM for all of my stacks, however just removing the script from the back breaks the IDE. Is there a list of IDE stacks that use the thing and if not, can one be provide, so I can have a plugin that only passes on GM related messages to the IDE stacks that need them? As soon as you work with more than 3 handful of controls, it becomes a pest vs. cholera situation. Either patch revCacheGeometry, to pass and thus breaking at least the property inspector, or wait for 3 Minutes (SIC!) to let revCacheGeometry do the job...

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5384
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: revGeometry

Post by FourthWorld » Sat Sep 21, 2013 1:33 am

I think the key to deactivating GM is to not use it. In my experience - as someone who never uses it at all - none of my objects have GM props so it never affects my work.

I agree that it would be nice to make it optional, and once we get an IDE contributor process set up I'd be happy to lend a hand with that.

But in the meantime, it may be worth a few minutes to write a script that strips all your objects of GM prop sets.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: revGeometry

Post by malte » Sat Sep 21, 2013 9:17 am

Hi Richard,

I never use it either, however, it does affect my work. :-) If you do have stacks with more than a couple of controls the backscript will always walk through all of them. If there is more than a thousand controls this is really really annoying. I am already down to the cause of this. This is because the IDE sends revCachegeometry at some point (without me wanting that, it just does). I have seen ways to optimize that handler, using the new controlIDs feature. However, as long as there is not an obvious way to contribute to the IDE, I just settle for the easy solution, which will be along the lines of this:

on revCacheGeometry
if the cGMLeaveMeAlone of this stack then pass revCacheGeometry

Cheers,

Malte

geoffcanyon
Posts: 15
Joined: Thu Aug 15, 2013 9:25 am

Re: revGeometry

Post by geoffcanyon » Mon Jan 06, 2014 3:03 pm

Malte, I noticed the same problem while editing the alignment tools in the properties palette. At a cursory review, revCacheGeometry doesn't seem to be object-specific, so I just pulled it out of the loop and inserted it after. Instant speed, and no issues so far. But I don't use the GM either, so anyone who does might suffer for making the change.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5384
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: revGeometry

Post by FourthWorld » Mon Jan 06, 2014 4:24 pm

malte wrote:Hi Richard,

I never use it either, however, it does affect my work. :-) If you do have stacks with more than a couple of controls the backscript will always walk through all of them. If there is more than a thousand controls this is really really annoying. I am already down to the cause of this. This is because the IDE sends revCachegeometry at some point (without me wanting that, it just does). I have seen ways to optimize that handler, using the new controlIDs feature. However, as long as there is not an obvious way to contribute to the IDE, I just settle for the easy solution, which will be along the lines of this:

on revCacheGeometry
if the cGMLeaveMeAlone of this stack then pass revCacheGeometry
I would consider the current behavior a bug. We cannot allow Rev scripts to monkey with native engine behaviors when they're not wanted. Please submit a report for that with your fix.

Know the engine.
Trust the engine.
Use the engine.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: revGeometry

Post by malte » Mon Jan 06, 2014 11:17 pm

Well, not sure if it is a bug. At least it is a sub optimal implementation. The problem with a geometry manager is that at some point it has to walk through all the controls on a card to do its job. That it does it always is an unfortunate implementation of a feature that might indeed be useful. However, the code in there is old and if I look at some of my code I wrote at the time the GM was developed I better keep my mouth shut. :-) Geoff is on to something I think. And the code for revCacheGeometry could be modernized to be quite a bit faster. For most projects it will not be noticeable, the effect is only to be seen with many controls on a card. And if you do not use the GM in the standalone all will be well. In the IDE it will remain a problem unless the code is modernized.

Post Reply

Return to “IDE Contributors”