use-revolution Digest, Vol 46, Issue 17

James Hurley jhurley0305 at
Tue Jul 10 14:36:26 EDT 2007

Wilhelm Sanke wrote:

> Hello Jim,
> your inventive script for the pencil tools proves once more that there
> are more than one or two approaches to achieve specific effects in
> x-talk languages. This is what most of us appreciate very much, and it
> surely challenges the creativeness of x-talk programmers.
> After the wonderful sunny Sunday - fine weather is rare these days in
> the middle of Europe - I took a second look at the various  
> questions and
> put together a sample and test stack "Hurley's Pencil"
> <>.
> The stack contains two images that can be reset after applying the
> pencil graphics (and it repeats most of the text of this post) and a
> radio-button group to change the paintcompression.
> There are now three different graphics to be dragged around on the  
> images:
> The red graphic contains a modified version of your original script,
> changing 4 pixels at once instead of 1 pixel on mousemove and using a
> variable "movedobject" instead of the name of the graphic to start and
> stop dragging.
> The yellow graphic contains an alternative script using a somewhat
> different approach based on my own basic format for the handling of
> imagedata. It enables you also to easily change the number of pixels
> involved when dragging the graphic.
> In the script of the green graphic
> line "set the imagedata of img "mine2" to idata"
> has been moved from the "mousemove" handler to the mouseup "handler",
> causing the image to be redrawn only after the moved graphic has been
> released.
> There are at least two basic problems for imagedata manipulation:
> 1. Processing imagedata with RLE paintcompression is up to 12 times
> faster  than with PNG (in extreme cases).
> See Bugzilla 5113 and the accompanying test stack
> <>
> Contrary to the Metacard IDE, Revolution sets the paintcompression to
> PNG on startup. If you use Revolution, set the paintcompression to RLE
> to speed up all imagedata processes. You can test the speed  
> differences
> by changing the paintcompression with the radio buttons at the top of
> the sample stack.
> 2. You can get and set the imagedata only for a whole image via a
> variable. You cannot access and change individual or a range of pixels
> directly like
> "put numtochar(100) into char 2500 of the imagedata of image "x"".
> This means that although by moving the pencil graphic only a few  
> pixels
> are changed, each time the graphic is moved the entire imagedata is
> being set anew (when using the red and yellow graphics).
> This also means that the larger the image the slower the possible
> movement of the pencil graphic will be. I tested this on an image
> 2048X1536 where the pencil graphic could be hardly moved even with the
> paintcompression set to RLE.
> Hopefully we will get such an enhancement to directly set the color of
> individual pixels in images in the future.
> Best regards,
> Wilhelm Sanke
> <>


Sorry to take so long in acknowledging your post. I subscribe only to  
the digest edition of this list and, more importantly, it takes me  
time to absorb all you  have to say. I particularly  appreciate  the  
user friendly format of your  presentation stacks.

I was totally unaware of the  compression options. Maybe  
paintCompression could be included in the "See also" collection that  
goes with the imageData entry in the dictionary.

It is certainly clear from your very helpful "HurleyPencil" stack  
that it pays  to paint with a broad brush. This also showed up  in my  
eraser stack.

The virtue  of the brush, as opposed to the pencil, is that, as it  
stutters along,  it will fill in those areas that might be skipped  
due to the slow processing speed in refreshing the imageData. The  
pencil also stutters along, but having writ, moves on, with no  
opportunity to back fill with the next stutter step.

I certainly agree with you that it would be a big help  if Run Rev  
would allow us  to change individual pixels rather than the whole  
image all at once.


More information about the Use-livecode mailing list