PDA

View Full Version : ambiguity with child image objects



myyoujh
03-04-2007, 11:11 PM
Please let me know whether OpenVG specification allows below implementation. ( comments with '//' mean implementation's return)

1> I1 = vgCreateImage(); // I1 <- 1
2> I2 = vgChildImage(I1, ...); // I2 <- 2
3> I3 = vgChildImage(I2, ...); // I3 <- 3
4> vgDestroyImage(I2); // destroying I2
5> Itmp = vgGetParent(I3); // Itmp <- 2
6> paint = vgCreatePaint(); // paint <- 2???
7> vgDestroyImage(I3); // destroying I3

Yes. I wonder whether the specification allows implementaion to return used handle identifier which was destroyed before, even if the identifier was a VGImage object having child images, and child images are not destroyed yet.

If the answer is 'No', inform me the proper pages on OpenVG specification document which can explain why the answer is no.

thanks.

Ivo Moravec
03-05-2007, 07:53 AM
According to the spec it looks valid. See page 111 - second paragrah of 10.6 Child Images.

Nils Pipenbrinck
03-05-2007, 12:18 PM
I wonder whether the specification allows implementaion to return used handle identifier which was destroyed before, even if the identifier was a VGImage object having child images, and child images are not destroyed yet.

That's a good question. My best bet is that it's not valid.

Page 14 of the 1.0 spec says:



Handles to distinct objects must compare as unequal using the C == operator.


There is not much room for interpretation :(.

Now another interesting question arises: After deleting a parent, should vgGetParent still return the parents handle? And if so, is it a valid handle for other OpenVG calls or not?
A quick test with the reference implementation shows, that vgGetParent returns the old parent-handle. It causes errors when used as an argument for vgClearImage though.

That's fine with the spec. Read up on vgDestroyImage (spec 1.0 page 107):



Following the call, the image handle is no longer valid in any context that shared it. If the image is currently in use as a rendering target, is the ancestor of another image (see vgChildImage), or is set as a paint pattern image on a VGPaint object, its definition remains available to those consumers as long as they remain valid, but the handle may no longer be used.


Btw, I found a bug related to this issue in my implementation as well (same as your example, except that I have to create an image instead of a paint). Looks like I have to delay the destruction of the handle and add a "deleted"-flag to my images.

Best regards,
Nils Pipenbrinck

Ivo Moravec
03-05-2007, 01:35 PM
According to the spec it looks valid. See page 111 - second paragrah of 10.6 Child Images.

Sorry - I misunderstood the question. I defer to Nils on this one until I find out more.

myyoujh
03-05-2007, 06:24 PM
thank you Ivo and Nils.

I read page 14 of spec says "Handles to distinct objects must compare as unequal using C == operator".

But I think that the term of "handle" above means only "alive handle".
And the spec doesn't mention what if the handles were destroyed aleady. Must they still be distinguishable even though they are dead and useless? That is ambiguous.

How can I get the OFFICIAL reply from Khronos?

myyoujh
03-05-2007, 06:49 PM
I asked this issue to AlexVG. (www.alexvg.com (http://www.alexvg.com) - mostly korean language)

and they said it depends on implementation, but their recommendation was 'no'. :(

Nils Pipenbrinck
03-07-2007, 08:09 AM
For your info:

The reference implementation code is out, so we could have a look.

vgGetParent now returns itself if the parent has been deleted.

myyoujh
03-07-2007, 06:17 PM
vgGetParent now returns itself if the parent has been deleted.

As I know current spec says vgGetParent returns its parent even if the parent is destroyed. (And you also said this on your first reply.)

Do you mean, it seems that the spec was modified?

Anyway thank you for your advice, I'm likely to follow the reference implementation. :lol: