Hi Adrian,
W.r.t ATI's and VetexArrays (VA) vs DisplayLists (DL), rather than
OSX, I'm certainly open to this change, but... one awkward aspect is
that one doesn't know the graphics hardware available until you have
a valid graphics context. Potentially you might even have several
cards form different vendors! The choice of whether to use VA or DL
would have to be done by the viewer, rather than the constructor of
DatabasePager. This should relatively straight forward to do,
something that could be done in somewhere like Viewer::realize().
W.r.t using a std::map rather than conventional list to speed up the
file request lookup. One sticking point is the the lists are
currently sorted by priority and this is key to the pagers ability to
make sure the most important tiles get merged first. So to do an
efficient lookup one would have to create a separate
map<std::string,DatabaseRequest*>, this will complicate some of the
code, but I guess it should still be possible to do this would too
many intrusive changes.
Robert.
On 8/28/07, Adrian Egli <[EMAIL PROTECTED]> wrote:
> i did a review of osgDB::DatabasePager and got some questions, or
> remarks....
>
> *******************************************************************************************************************
> ../src/osgDB/DatabasePager.cpp @ Ln72
>
> #if __APPLE__
> // OSX really doesn't like compiling display lists, and performs poorly
> when they are used,
> // so apply this hack to make up for its short comings.
> _drawablePolicy = USE_VERTEX_ARRAYS;
> #else
> _drawablePolicy = DO_NOT_MODIFY_DRAWABLE_SETTINGS;
> #endif
>
>
> I don't believe that this is just an __APPLE__ performance problem. The
> problem is that on ATI Cards,
> most of APPLE OS/X computers are based on ATI, nowadays latest MacBooks Pro
> have NVIDIA, but most Apple
> Computers are based on ATI cards. And as we know, that on ATI DisplayList
> compiling is really poorly
> implemented, i propose to read vendors back from the graphics card, and if
> we were working on ATI based
> graphic system, we switch directly to vertex arrays.
>
> glVender.string.has("ATI") => vertex arrays
>
> *******************************************************************************************************************
> ../src/osgDB/DatabasePager.cpp @ Ln290
>
>
>
> OpenThreads::ScopedLock<OpenThreads::Mutex>
> lock(_dataToCompileListMutex);
>
> for(DatabaseRequestList::iterator litr =
> _dataToCompileList.begin();
> litr != _dataToCompileList.end() && !foundEntry;
> ++litr)
> {
> if ((*litr)->_fileName==fileName)
> {
> foundEntry = true;
> (*litr)->_frameNumberLastRequest =
> frameNumber;
> (*litr)->_timestampLastRequest = timestamp;
> (*litr)->_priorityLastRequest = priority;
> ++((*litr)->_numOfRequests);
> }
> }
>
> ...
>
>
> if we have a huge database with many level of request, once had more than
> 200(!) requests per frame [calls of requestNodeFile].
> then we have to walk trough the database say sum of i from 1:x = (x*(x+1) )/
> 2, instead of log(x), i propse to use a
> std::map or a std::multimap instead of a std::list of database request. of
> course we will use more memory, but the performance can be increased.
> (called in each cull pass / at each frame ) => Time Critical
> *******************************************************************************************************************
>
>
>
> /adegli
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
