Re: Eraser tool
J. Landman Gay wrote: Tariel Gogoberidze wrote: Eraser tool works fine in MC IDE 2.6 and engine vs 2.6.6 build 152 Both from message box and from Paint tool palette. I think it's last IDE Richard posted, 2.6b12 or 2.6r1 ? Anyway, from about box it's 2.6b12 but not sure Richard changed this in IDE 2.6r1 I checked on OS X 10.3.9 I was just checking on this again. I can't get the spray can, brush tool, or eraser to work. They're all inert. :( I also can't find anything in the frontscript or the paint tools stack that would stop these from working. I'm pretty sure the engine is okay. Hmmmstranger still is that all tools are now working here. I never use the paint tools so I can't explain how the behavior changes. Once upon a time there was an issue with the select tool, and IIRC I found scripts in Rev which worked around it. But that was a while back and my memory may be faulty -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Eraser tool
Tariel Gogoberidze wrote: Eraser tool works fine in MC IDE 2.6 and engine vs 2.6.6 build 152 Both from message box and from Paint tool palette. I think it's last IDE Richard posted, 2.6b12 or 2.6r1 ? Anyway, from about box it's 2.6b12 but not sure Richard changed this in IDE 2.6r1 I checked on OS X 10.3.9 I was just checking on this again. I can't get the spray can, brush tool, or eraser to work. They're all inert. :( I also can't find anything in the frontscript or the paint tools stack that would stop these from working. I'm pretty sure the engine is okay. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Controlling PDFs in Player Object on Mac
Using MC 2.5 on Mac OSX, I can show a multi-page PDF file in a player object. But I can't figure out how to write a script that will control what page is showing. For the several example PDF files I've tried, the player's timeScale is 600 and its duration seems to be something like 75 times (z-1) where z is the number of pages in the PDF. But "set the currentTime of player 1 to (n-1)*75" does not consistently cause page n to be shown. Does someone know how to do this, or where I can learn how to do this? Many thanks. David Epstein ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
Wilhelm Sanke wrote: In the meantime I did further tests and built standalones for MC 2.6.5, 2.73, 2.74 and Rev 2.6.1, 2.73, 2.74. I tested 3 more scripts and also tested all scripts with a much larger image of 1600 X 1200. As before, no significant differences between stacks and standalones in MC and - also as before - a slight improvement for the Rev standalones compared to the Rev stacks, but a remaining difference to the MC equivalents of up to four seconds, and even one script where Rev runs *eleven* times slower than MC! See below. Very valuable info for RunRev. Thanks for taking the time to verify that test. It now remains to be found out which script is responsible for this abject treatment of imagedata in Revolution, where this script is located, and how we can prevent its interference. I'm wondering if it isn't script execution at all, but perhaps memory. I can't think of any way your script could be affected by the mere existence of other scripts, since your main handler is pretty well self-contained (so "send" or other such things which might give RR's scripts some chance to intercede). I don't believe that the scripts RR's standalone maker insists on adding to one's project are all that large, but perhaps in an intensive environment such as your image processing script requires the difference may be just enough to affect performance. How much RAM is installed on your machine? I'm grasping at straws here, but this is such an unexpected result that as far as causes go it may be worth remaining open to possibilities which may even seem unlikely. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Speed differences between MC and Rev (problem area nearly found)
Richard Gaskin wrote:
Confirmed in the IDEs -- 5740ms/avg in MC, 6830ms/avg in Rev (I have a
1GHz PB G4).
I haven't built standalones, though, which would be good to test.
In the meantime I did further tests and built standalones for MC 2.6.5,
2.73, 2.74 and Rev 2.6.1, 2.73, 2.74. I tested 3 more scripts and also
tested all scripts with a much larger image of 1600 X 1200.
As before, no significant differences between stacks and standalones in
MC and - also as before - a slight improvement for the Rev standalones
compared to the Rev stacks, but a remaining difference to the MC
equivalents of up to four seconds, and even one script where Rev runs
*eleven* times slower than MC! See below.
Given this speed loss I'm confident the folks at RunRev will take a keen
interest to determine what's eating performance.
Offhand I can't imagine how the execution of a single handler with no
breaks, pauses, or sends is in any way affected by any outside script,
but it does indeed appear to be the case.
Have you BZ'd this? It would be good to include that file as an
attachment to the report.
I might do this after some more research
-- Richard Gaskin Fourth World Media Corporation
and Chipp Walters (on Wed, 11 Oct 2006) wrote:
Wilhelm,
Just wondering, did you 'lock messages' before and 'unlock messages'
after when running the script? If not, you might want to try it and
see if it doesn't speed things up.
Inserting "lock messages" etc. does not change the results.
But thanks for the hint, because the fact that adding "lock messages"
does not change the speed means that the long
"setProp cREVGeneral [pwhichProp] pWhichProfile" handler
(which belongs to the scripts added by the Rev Standalone Builder)
cannot be the culprit.
Unfortunately, all these extra scripts apparently are added by the
script-protected revsaveasstandalone substack. I searched the scripts of
the "StandaloneSettings" stacks and so far found nothing there that
could be related to the speed difference problems.
Also, you probably want to make sure 'Variable Checking by Default" is
turned OFF in the prefs pane for RR.
Same as above, does not make any difference.
best, Chipp
Here are some results for filters applied to the larger 1600 X 1200
image (again: Windows computer with 2 GHz):
- "duplicate colors": Rev is * three seconds* slower in all the 3 stacks
and standalones ( 9 vs. 12 and 10 vs. 13 seconds with different engine
versions)
- "max dots" (this is a modified version of the Gimp "despeckle"-median
filter, where I exchanged the median for the max values. The button is
to be found in my Imagedata Toolkit below the "despeckle" filter).
Rev is about 4 seconds slower here, the results being 34 seconds for MC
and 38.5 for Rev on the average.
I then happened to notice that the reset button worked considerably
slower in Rev, eleven times slower, and I measured this.
The script of the reset button is a one-liner
"set the imagedata of img 1 to decompress(the Bilddaten of me)" --
("Bilddaten" being a translation of imagedata).
This takes 270 milliseconds in MC and 3000 milliseconds in Rev with all
engine versions and identical in stacks and standalones.
I removed "compress" for setting the custom property and "decompress"
then in the reset handler, which didn't make much of a difference: Rev
is now only 10 times slower.--
Anyway, after the "compress-decompress-reset" tests, I made some
progress in detecting what is involved in producing the speed-difference
problems. Instead of the image I placed a field with a longer text on
the card, which then was saved as a custom property of the reset button.
Resetting the text of the field is indeed identical in all Rev and MC
stacks and standalones, meaning
that the speed differences between MC and Rev are caused by a different
handling of "imagedata"!
It now remains to be found out which script is responsible for this
abject treatment of imagedata in Revolution, where this script is
located, and how we can prevent its interference.
Best regards,
Wilhelm Sanke
___
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
