yang686526

any alternative to oddbviewporttablerecord::zoomextents()?
any alternative to oddbviewporttablerecord::zoomextents()?
hi,
we use dd for both import and export from our app.
during export after writing all entities, we call zoomextents() so that when the user opens the file in autocad, we gets to see all the entities.
during import we need to map all entities whether or not they are in the view. we're using vectorization, hence for modelspace we call zoomextents() on the active viewport, delete all other viewports and call oddbgsmanager::setuplayoutviews() with the layout id of modelspace layout to set up vectorization.
this scheme work fine, except in few cases when the drawing contains a lot of entities. for some drawings containing large number of entites (especially hatches) we've observed that the call to zoomextents() take up large amount of time as well as memory.
has anyone experimented with better alternatives for these problems?
in particular:
1. can we find the extents that all entites span? (for calculating this we currently call zoomextents() on a view and and then take width and height.)
2. can we tell the vectorizor to vectorize all entities while vectorizing modelspace layout without calling zoomextents() first?
thanks,
varun
last edited by varunsnair; 6th april 2006 at 06:38 amfff">. reason: correcting title
oddbdatabase::setfillmode(false) should speed up oddbviewporttablerecord::zoomextents() when rendering hatch, 2d solids, and wide polylines.

writing:
code:
bool prevfillmode = pdb->getfillmode();
pdb->setfillmode(false);
pdb->zoomextents();
pdb->setfillmode(prevfillmode);
did reduce the time zoomextents() takes to executes.
are there any side-effects of this that i should be aware of?
i am doing this during import, before vectorization to bring all objects into view.
thanks,
varun
quote:
originally posted by varunsnair
are there any side-effects of this that i should be aware of?
i am doing this during import, before vectorization to bring all objects into view.
thanks,
varun
hatch without boundary entities will not be included in the extents computation.
defeats the whole purpose then doesn't it!
thanks,
varun
hatch is usually associative (has boundary entities). the only time you'll run into problems is if a boundary were deleted after creating the hatch, and the hatch itself defined the extents.
oddbhatch::worlddraw() is already optimized in the case of extent calculations, so there's nothing else (we know of) that you can do.