Prev: regarding logging
Next: usage of new "in" and "ni" expression operators
From: Miroslaw on 4 Jul 2008 05:41
Hi,

I noticed the following code executes FASTER after changing
both occurrences of {incr ... 4} to {incr ... 1}.
I expected the contrary.

I tested the code with wish8.4 and wish8.5 and
"incr 1" version completed in 15sec, while "incr 4"
version completed in 50sec.
Could anybody explain that?
Thx,

--------------------------------------
#!/bin/sh
# the next line restarts using wish \
exec wish "$0" "$@"

image create photo img -width 400 -height 400
img blank
label .area -image img -background white
pack .area

proc put {x y col} {
img put $col -to $x $y
}

proc color {x y} {
return #0000aa
}
for {set x 0} {$x < 400} {incr x 4} {
for {set y 0} {$y < 400} {incr y 4} {
put $x $y [color $x $y]
}
update
}
for {set x 0} {$x < 400} {incr x 1} {
for {set y 0} {$y < 400} {incr y 1} {
put $x $y [color $x $y]
}
update
}

exit
From: Andreas Leitgeb on 4 Jul 2008 07:59
Miroslaw <omirek10(a)poczta.onet.pl> wrote:
> I noticed the following code executes FASTER after changing
> both occurrences of {incr ... 4} to {incr ... 1}.
> I expected the contrary.
>
> image create photo img -width 400 -height 400
> img blank
> proc put {x y col} {
> img put $col -to $x $y
> }
So, you're filling tk-images...
Doing that pixel for pixel is inherently slow, btw., but
in the "incr ... 4"-case, inevitable.

The difference may be, that in one case you end up with
a 100% opaque image, whereas in the "4" case, you end up
with about 6% opaqueness, that is almost entirely transparent.

Another possible reason could be, that you did the tests
in sequence (both within the same script), and the first
block "paved the way" for the second. If it's that, then
by reversing the blocks (do the "1" first, then the "4")
you'd see the "1"-case slowing down, and the "4" case
speeding up.

From: Miroslaw on 4 Jul 2008 09:16
On Jul 4, 11:59 am, Andreas Leitgeb <a...(a)gamma.logic.tuwien.ac.at>
wrote:
>
> The difference may be, that in one case you end up with
> a 100% opaque image, whereas in the "4" case, you end up
> with about 6% opaqueness, that is almost entirely transparent.
>
> Another possible reason could be, that you did the tests
> in sequence (both within the same script), and the first
> block "paved the way" for the second.

Thanks for tips.
I tried code in separate scripts, version A, then B, then A;
therefore results are reliable.
Also, after reading your tip about opacity I tried everything without
both "update" lines. The results are the same... (of course window is
never visible in that case).

Perhaps, internal representation of images is not optimized
for some configurations of opaque/transparent regions.

Any new ideas are welcome,
Thx



From: Alexandre Ferrieux on 4 Jul 2008 10:10
On Jul 4, 3:16 pm, Miroslaw <omire...(a)poczta.onet.pl> wrote:
>
> Perhaps, internal representation of images is not optimized
> for some configurations of opaque/transparent regions.

Yes, it seems so.
I've just looked at Tk_PhotoPutBlock which implements [img put], and
it turns out that each and every [put] recalculates for each rwo the 1-
D region on non-transparent pixels. In your step-1 loop this region is
just a growing contiguous interval, while in your step-4 it is an
expanding list of length-1 intervals, where the Union operation works
in O(N) !

Question to the designer (Donal?): couldn't we arrange so that this
region be recomputed in a lazier fashion instead of after each and
every [img put] ? I understand that it may be needed in the very next
[put], but only if the source pixels have any transparency; maybe
there's room for optimizing the interesting special case of no-
transparency-in-source ?

-Alex

(1)
From: Miroslaw on 5 Jul 2008 00:37
On Jul 4, 4:10 pm, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
> On Jul 4, 3:16 pm, Miroslaw <omire...(a)poczta.onet.pl> wrote:
> > Perhaps, internal representation of images is not optimized
> > for some configurations of opaque/transparent regions.
>
> Yes, it seems so.
> I've just looked at Tk_PhotoPutBlock which implements [img put], and
> it turns out that each and every [put] recalculates for each rwo the 1-
> D region on non-transparent pixels. In your step-1 loop this region is
> just a growing contiguous interval, while in your step-4 it is an
> expanding list of length-1 intervals, where the Union operation works
> in O(N) !

Thanks for that, now I found simple solution -- filling image with
color.
So after line:
img blank
I added:
img put #ffffff -to 0 0 399 399
for filling image with color and, more important, opacity.
Now incr-4 version completes in 9sec while incr-1 in 14 sec.
and this make sense now.

Thanks folks,
 |  Next  |  Last
Pages: 1 2
Prev: regarding logging
Next: usage of new "in" and "ni" expression operators