Re: Question #6 : jig-saw puzzles
I'm not an expert on this, but I've been wondering about it myself.
The way I would conceive of it being would be like this:
<clipPath id="shape1"... />
<clipPath id="shape2"... />
<clipPath id="shape3"... />
<clipPath id="shape4"... />
<image id="myImage" xlink:href="foo.png".../>
<use id="piece1" clipPath="url(#shape1)" xlink:href="url(#myImage)".../>
<use id="piece2" clipPath="url(#shape1)" xlink:href="url(#myImage)".../>
<use id="piece3" clipPath="url(#shape2)" xlink:href="url(#myImage)".../>
<use id="piece4" clipPath="url(#shape2)" xlink:href="url(#myImage)".../>
<use id="piece5" clipPath="url(#shape3)" xlink:href="url(#myImage)".../>
I'm not positive I've got the above right, but it seems to me that if
you can do the above then SVG implementations don't NECESSARILY have
to make full copies of the entire raster image if they're efficient
enough. They could parse it, determine the pixel area that's included
and make a copy of that region only.
Unfortunately, at least Firefox uses full copies for its <use>
elements (as far as I remember). I don't know about Adobe or Opera.
I guess this is a "wait-until-the-implementations-catch-up" type of
--- In email@example.com, david dailey
> My list of unanswered questions has been given a more lasting home.
> If you have not enough troubles of your own, please see
> http://srufaculty.sru.edu/david.dailey/svg/svg_questions.htm) for
> things that have been troubling me.
> Of particular interest to me of late has been #6 concerning jig-saw
> puzzle carving. Here's what I have figured out:
> 6. To make a jig-saw puzzle using SVG, one may
> a) chop up an image into little movable chunks using numerous
> clipPaths applied to numerous copies of an image (see for example,
> The problem is that this appears to use lots and lots of RAM and bogs<http://srufaculty.sru.edu/david.dailey/svg/later/displace2.svg>attempt1
> down when the number of rows and columns gets large. For those using
> IE/ASV see also http://marble.sru.edu/~ddailey/svg/clipembed16.html
> in which the loci of clipPaths are permutable according to a
> user-supplied string of less than rows x cols characters.
> b) <http://srufaculty.sru.edu/david.dailey/svg/later/offsets7.svg>use
> feOffset's and feTile's to slice an image (be prepared to wait a
> while for it to render). I didn't see any easier way to grab the
> parts I wanted to move than this. It is way too time-consuming (I
> assume this is processor rather than RAM related) to be practical on
> a large scale.
> c) build a checkerboard of red-scale values underneath the image and
> then distort the image using <feDisplacementMap> and the
> red-channel. See
> by way of illustration. The approach looks like it will be fast and<http://srufaculty.sru.edu/david.dailey/svg/later/displace7.svg>attempt3).
> generalize easily to large images with lots of slices. The hassle is
> that the exact distance by which pixels are moved, while clearly
> related to the displacement's scale attribute and the red-scale value
> of the underlying map, seem not to be entirely predictable (see
> The <http://www.w3.org/TR/SVG11/filters.html#feDisplacementMap>W3C
> spec actually spells out how the pixel loci will move, so maybe I'm
> just misreading it. The other hassle, of course, is that this uses
> filters and not many browsers are currently handling it.
> Is there an easier way? Can I somehow just grab the pixels out of a
> rectangular section of a bitmap in SVG and move (just) them around? I
> think I may just be missing something key in the SVG tool set.
> [Non-text portions of this message have been removed]