yang686526

bug(?) in odgibasevectorizer when gsmodel is enabled
bug(?) in odgibasevectorizer when gsmodel is enabled
we are still on dd 1.13.xx, so if this is a bug, it may already be fixed.
we are using the wingdi renderer with gsmodel enabled.
we recently encountered a problem whereby modifying a layer's on/off status, regenerating the cache, and then repainting the screen did not yield the correct results. turning the layer off resulted in the elements still being drawn, while turning the layer on resulted in the elements not being drawn.
the problem seems to be related to this code in odgibasevectorizer:
code:
void odgibasevectorizer::updatelayertraits(odgisubentitytraitsdata& subentitytraits) const
{
if(m_layerid!=subentitytraits.layer())
{
m_layerid = subentitytraits.layer();
odgidrawableptr player = m_pcontext->opendrawable(subentitytraits.layer());
if (player.get())
{
m_layertraitsdata.set(player);
// logical cohesion with db : gs implementation must "know" that layer may be from xref
m_effectivelayerid = player->id();
}
else
{
m_layertraitsdata = layertraits();
m_effectivelayerid = 0;
}
}
::setlayerflagstotraits(subentitytraits, m_layertraitsdata.flags(), m_pcontext->isplotgeneration());
}
when the drawing traits are updated (for each element that is processed), odgibasevectorizer::updatelayertraits saves the layer id and the layer traits. as long as elements are on the same layer, the same layer traits can be used without having to resolve the layer id and retrieve the traits again. in our case, we had a dxf file with some layers, call them a, b, c. each layer had some elements, call them a1, a2, ..., b1, b2, ..., etc. as it turns out, the elements appeared in the file like this: a1, a2, a3, ..., b1, b2, b3, ..., c1, c2, c3, ... that is, for a given layer, all of its elements were stored consecutively in the file. now, turn on a and turn off b and c. invalidate the cache (invalidategsmodel). redraw the screen (using wingdi renderer).
as the file is processed, first the new cache is generated. odgibasevectorizer::updatelayertraits is executed for each element that is processed. only elements from layer a are added to the cache because layers b and c are off. at the end of the cache generation phase, odgibasevectorizer has saved the m_layerid and associated layer traits associated with layer c, since the last element in the file is on layer c.
after the cache has been generated, it is drawn to the screen. the cache contains only elements from layer a. during the drawing, odgibasevectorizer::updatelayertraits is called for each element (from the cache) that is drawn. at the end of drawing the cache to the screen. odgibasevectorizer has saved the m_layerid and associated layer traits associated with layer a, since the last element that was drawn from the cache to the screen is on layer a.
now, turn off layer a, invalidate the cache, and repaint the screen.
again, the file must be processed to create the new cache. while processing the elements from layer a, odgibasevectorizer::updatelayertraits notes that its saved m_layerid is the same as the layer id of the elements, so it does not get the current layer traits. the last time that m_layerid and its associated layer traits were saved, layer a was on, so the saved traits reflect that. therefore, the elements from layer a are added to the cache with their layer status as "on", even though the current on/off status of layer a is "off". after all elements have been processed and, if necessary, added to the cache, the cache is drawn to the screen. since the cache contains the elements from layer a, those elements are drawn to the screen, even though the current status of layer is that it is "off".
i have not been able to reproduce the problem in odamfcapp, but i haven't debugged through it to see exactly why.
to work around the problem, i added the following redfff"> lines to exgdivectorizeview::update, before sending the update to odgsbasevectorizeview:
code:
odgisubentitytraitsdata myfromtraits;
odgisubentitytraitsdata mytotraits;
affecttraits(&myfromtraits,mytotraits);
odgsbasevectorizeview::update();
the effect is to clear odgibasevectorizeview's saved m_layerid and its associated traits. in the situation that i described above, the layer id for layer a is cleared. as the new cache is being generated, when the layer a elements are encountered, their layer id does not match the saved layer id (since the saved layer id has been cleared), so the current layer traits must be retrieved. that ensures that, when the cache is generated, it always starts with the current state of all of the layers, not that layer state as it existed the last time that the cached representation of the drawing was drawn to the screen.
i am attaching the dxf file that exposed this problem. i don't think that there is anything particularly special about the file, other than the element layout is as i described. in the case of this file, the "houses" layer is the layer that was causing our problems.
attached files
i just wanted to bump this post to the top again. since we have implemented a fix as described in my original post, we are not waiting on a fix from the dd guys.
however, if you have read the post and if the information that i provided sufficiently explained the problem (or my interpretation of it, anyway), i wanted to know if dd agrees with my assessment and whether this problem will be addressed in a future version?
thanks.
hi,
there was a bug (cr 2827) that had been fixed in dd 1.13.04 by clearing m_layerid in odgsbasevectorizeview::beginviewvectorization().
thanks for the information! we have been stuck on a slightly older version of dd for a while now. we hope to upgrade to the current version very soon.