[Bf-committers] Re: Slow Render Bug in 2.25
John K. Walton
bf-committers@blender.org
Fri, 3 Jan 2003 07:08:28 -0500 (EST)
On Fri, 3 Jan 2003, Ton Roosendaal wrote:
> Hi,
>
> I've asked Daniel Dunbar, who worked at NaN to get OpenGL working for
> all 3d cards out there... when we released 2.25 the new nvidia
> detonators drivers were quite crap. We had to do some patching to get
> it working again. There are some OpenGL flushes there that could be
> tweaked. According to Daniel, the 'render bug' only shows up at Nvidia
> systems, ATI works fine.
>
> What should be further worked on are the pixel drawing commands during
> the rendering process.
> Opening (and closing) a 2nd window with OpenGL context is also
> something not all 3d cards handle nicely. For that reason we were
> thinking of using a Blender 'Image' window to do the drawing in.
I remember there being a big hit to image quality for 24 bit
sgi systems with this plan. we needs to support both methods.
> It would be quite handy when we put our NaN cvs server online. That's
> one of the things at the todo list here... none of these files have a
> proper license (GPL) and some of the files have to be removed (like
> Solid). Maybe it's sufficient to have cvsweb access to the repository,
> then at least you've got insight in the history.
>
> -Ton-
>
> On Wednesday, Jan 1, 2003, at 19:06 Europe/Amsterdam, Chris Want wrote:
>
> > My personal opinion is that more analysis should be done
> > on this, lest we commit a patch that only tackles a
> > symptom of a larger problem. My rational for this stance
> > is that in the 1.8 sources, the function 'test_break'
> > (this cooresponds to be the current 'RE_local_test_break')
> > gets called about as many times as it does in the
> > current sources, but the rendertimes were more reasonable.
> > I think the real problem is an issue in the ghost libs, and
> > in particular the speed at which events are dispatched and
> > handled (the 1.8 sources used the glut event stuff).
> >
> > Anyways, if nothing else, it's something to think about.
> > There is also still a slow down in the commandline
> > rendering that can not be attributed to this
> > event polling issue.
> >
> > Regards,
> > Chris
> >
> >
> > Robert Wenzlaff wrote:
> >> Here's the patchfiles for
> >> blender/source/blender/render/intern/source/rendercore.c
> >> and
> >> blender/source/blender/render/intern/source/zbuf.c
> >> to fix the slow render problem. I'm gonna have to get around to
> >> asking for CVS write access on of these days....
> >> ----------------------------------------------------------------------
> >> --
> >> --- zbuf.c Wed Jan 1 11:27:04 2003
> >> +++ zbufmod.c Wed Jan 1 11:24:28 2003
> >> @@ -25,7 +25,7 @@
> >> *
> >> * The Original Code is: all of this file.
> >> *
> >> - * Contributor(s): none yet.
> >> + * Contributor(s): Hos, RPW.
> >> *
> >> * ***** END GPL/BL DUAL LICENSE BLOCK *****
> >> */
> >> @@ -2121,7 +2121,7 @@
> >> }
> >> }
> >> }
> >> - if(RE_local_test_break()) break;
> >> + if(!(v%256)&&RE_local_test_break()) break; /*RPW, HOS */
> >> }
> >>
> >> if((R.r.mode & R_OSA)==0) break;
> >> ----------------------------------------------------------------------
> >> --
> >> --- rendercore.c Wed Jan 1 11:27:02 2003
> >> +++ rendercoremod.c Wed Jan 1 11:24:45 2003
> >> @@ -25,7 +25,7 @@
> >> *
> >> * The Original Code is: all of this file.
> >> *
> >> - * Contributor(s): none yet.
> >> + * Contributor(s): Hos, Robert Wenzlaff.
> >> *
> >> * ***** END GPL/BL DUAL LICENSE BLOCK *****
> >> */
> >> @@ -1055,8 +1055,10 @@
> >> if((a & 255)==0) har= R.bloha[a>>8];
> >> else har++;
> >> - if(RE_local_test_break()) break;
> >> -
> >> + if(!(a%256)&&RE_local_test_break()) break; /* Hos, RPW - fix slow
> >> render bug, */
> >> + /* !(loopvar%256) keeps checking for */
> >> + /* ESC too often and bogging down render */
> >> + /* (Based on discovery by Rob Haarsma) */
> >> if(ys>har->maxy);
> >> else if(ys<har->miny);
> >> else {
> >> @@ -1078,7 +1080,7 @@
> >> for(x=minx; x<=maxx; x++) {
> >>
> >> flarec= har->flarec; /* har->pixels mag maar 1 x geteld worden
> >> */
> >> -
> >> +
> >> if( IS_A_POINTER_CODE(*rd)) {
> >> xn= x-har->xs;
> >> xsq= xn*xn;
> >> @@ -1162,7 +1164,7 @@
> >> if((a & 255)==0) har= R.bloha[a>>8];
> >> else har++;
> >> - if(RE_local_test_break()) break;
> >> + if(!(a%256)&&RE_local_test_break()) break;/*Hos, RPW, fixes Slow
> >> Render Bug*/
> >> if(ys>har->maxy);
> >> else if(ys<har->miny);
> >> @@ -1216,7 +1218,7 @@
> >> if((a & 255)==0) har= R.bloha[a>>8];
> >> else har++;
> >> - if(RE_local_test_break()) break;
> >> + if(!(a%256)&&RE_local_test_break()) break;/*Hos, RPW, fixes slow
> >> render bug */
> >> if(har->maxy<0);
> >> else if(R.recty<har->miny);
> >> @@ -1270,7 +1272,7 @@
> >> rectt+= R.rectx;
> >> rectz+= R.rectx;
> >>
> >> - if(RE_local_test_break()) break;
> >> + if(!(y%256)&&RE_local_test_break()) break;/*Hos,RPW, Fixes slow
> >> render bug */
> >> }
> >> }
> >> @@ -2489,7 +2491,7 @@
> >> /* 1 is voor osa */
> >> if(R.r.mode & R_EDGE) edge_enhance();
> >>
> >> - if(RE_local_test_break()) break;
> >> + if(!(v%256)&&RE_local_test_break()) break; /*Hos,RPW, fixes slow
> >> render bug*/
> >> }
> >> if(R.flag & (R_ZTRA+R_HALO) ) { /* om de juiste zbuffer Z voor
> >> transp en halo's terug te halen */
> >> xd= jit[0][0];
> >> @@ -2621,7 +2623,7 @@
> >> }
> >> rz+= R.rectx;
> >> }
> >> - if(RE_local_test_break()) break;
> >> + if(!(y%256)&&RE_local_test_break()) break; /*Hos,RPW, fixes slow
> >> render bug */
> >> }
> >> if( (R.r.mode & R_EDGE) && RE_local_test_break()==0) {
> >> @@ -2722,7 +2724,7 @@
> >> R.rectot);
> >> }
> >>
> >> - if(RE_local_test_break()) break;
> >> + if(!(y%256)&&RE_local_test_break()) break; /*Hos,RPW, Fixes Slow
> >> render bug */
> >> }
> >> if(R.flag & R_ZTRA) endaccumbuf();
> >> @@ -2785,7 +2787,7 @@
> >>
> >> rectt+= R.rectx;
> >>
> >> - if(RE_local_test_break()) break;
> >> + if(!(y%256)&&RE_local_test_break()) break; /* Hos,RPW, fixes
> >> slow render bug */
> >> }
> >>
> >> }
> >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://www.blender.org/mailman/listinfo/bf-committers
> >
> >
> ------------------------------------------------------------------------
> --
> Ton Roosendaal Blender Foundation ton@blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>