Results 1 to 8 of 8

Thread: ambiguity with child image objects

  1. #1
    Junior Member
    Join Date
    Mar 2007
    Location
    seoul
    Posts
    4

    ambiguity with child image objects

    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.

  2. #2
    Senior Member
    Join Date
    Feb 2006
    Posts
    115

    Should be perfectly fine

    According to the spec it looks valid. See page 111 - second paragrah of 10.6 Child Images.

  3. #3

    Re: ambiguity with child image objects

    Quote Originally Posted by myyoujh
    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

  4. #4
    Senior Member
    Join Date
    Feb 2006
    Posts
    115

    Re: Should be perfectly fine

    Quote Originally Posted by Ivo Moravec
    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.

  5. #5
    Junior Member
    Join Date
    Mar 2007
    Location
    seoul
    Posts
    4

    Re: ambiguity with child image objects

    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?

  6. #6
    Junior Member
    Join Date
    Mar 2007
    Location
    seoul
    Posts
    4

    Re: ambiguity with child image objects

    I asked this issue to AlexVG. (www.alexvg.com - mostly korean language)

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

  7. #7
    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.

  8. #8
    Junior Member
    Join Date
    Mar 2007
    Location
    seoul
    Posts
    4
    Quote Originally Posted by Nils Pipenbrinck
    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.

Similar Threads

  1. Image objects
    By lucafr in forum OpenCL
    Replies: 1
    Last Post: 07-25-2011, 03:37 AM
  2. Replies: 0
    Last Post: 06-14-2011, 02:04 AM
  3. Replies: 5
    Last Post: 01-13-2010, 12:34 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •