[Bf-committers] mousewheel delay...

[John K. Walton]

hey rob!
the delay was from the first NaN code release non free under 2nd NaN :-)

On Fri, 15 Aug 2003, Rob Haarsma wrote:

> Heya,
> 
> Maybe the lag is caused by the mousewheel zoom/move integration ?
> Did previous versions (< 2.26) also have this delay ?
> 
> Rob
> 
> 
> 
> Ton Roosendaal wrote:
> 
> > Hi,
> >
> > While IRC-ing with someone using O2 (Jiri), I asked about this  
> > middlemouse lagging problem. He could reproduce it, and gave a few 
> > nice  clues;
> >
> > - tools like Grabber don't have delay
> > - middlemouse rotate in 3D window always gives 0.5 second delay
> > - middlemouse move in other windows goes OK
> > - SHIFT+middlemouse doesn't have the delay in 3d Window
> >
> > which point to something in Blender code, not to Ghost. The 
> > view-rotate  feature in is blender/src/view.c, void viewmove(int 
> > mode). I can hardly  find things that really differ between code for 
> > rotating or translating  (with SHIFT).
> >
> > Can you confirm this, and find the other locations in Blender 
> > interface  that have delays always?
> > I suspect it's the changes in Blender's swapbuffers method, which 
> > also  has changed while Ghost was introduced...
> >
> > -Ton-
> >
> >
> > On Tuesday, Aug 12, 2003, at 17:10 Europe/Amsterdam, John K. Walton  
> > wrote:
> >
> >>
> >>
> >> While I agree with everything you said, there are serious performance
> >> problems in 3d window with ghost based versions. mips3, or older
> >> O2's suffer from annoying lag when rotating (and stuff), as if it's
> >> polling at a low rate and missing the mouse action. once the action
> >> gets going, it's ok.impact type systems (which were the only ones
> >> after early blender days) never had this problem.
> >>
> >> my understanding behind externalizing ghost was to make the display
> >> subsystem independant (a good thing). one use for this would be to
> >> use GLUT (even if it is ugly, everything is ugly from one perspective
> >> or another) when appropriate, and ghost when appropriate or some
> >> distributed multidisplay visualization thing. and not just to make
> >> an arbitrary API.
> >>
> >> to summarize, I'm looking for an opportunity, not applying a  
> >> restriction
> >> or objecting in anyway, I've got enough hardware, I can benefit from
> >> anything short of dropping everythign except OSX ;-)
> >>
> >> On Tue, 12 Aug 2003, Ton Roosendaal wrote:
> >>
> >>> Hi,
> >>>
> >>> Apart from a major missing feature (24 bits display) ghost works
> >>> technically much better than Glut. In '98 I had to to do lot of hacks
> >>> in the glut code to make it working, and it was needed to patch  
> >>> Blender
> >>> for it too. This was so much more ugly and awkward than the previous
> >>> used nice irisgl windowing lib.
> >>> Glut has (and had) no official ports for BeOS or OSX available (the
> >>> current beGlut and OSX-glut are forks), which made & makes porting
> >>> Blender very cumbersome.
> >>>
> >>> I've checked your forwarded comments from Zr on adding 24 bits support
> >>> for Ghost. It really requires someone with more Ghost and C++ insight
> >>> and an X11 development envirmont to do it.
> >>>
> >>> There's a load of unix coders here though... nobody interested in cool
> >>> single buffered 24 bits display for rendering?
> >>>
> >>> (from zr:)
> >>> The quick fix solution would be:
> >>> Add single buffer mode argument to C++ ghost constructor
> >>> Add same arg to GHOST_CreateWindow
> >>> Add same arg to window_open
> >>> Add code to renderwin.c to determine what mode to use.
> >>>
> >>> I can help with renderwin.c, that's what I'm familiar with.
> >>>
> >>> -Ton-
> >>>
> >>>
> >>> On Tuesday, Aug 12, 2003, at 15:48 Europe/Amsterdam, John K. Walton
> >>> wrote:
> >>>
> >>>> On Mon, 11 Aug 2003, Ton Roosendaal wrote:
> >>>>
> >>>>> 2. ghost
> >>>>> - the Ghost team intends to go for an 'official launch'... they're
> >>>>> finalizing docs and demos for it. Ton will help getting marketing
> >>>>> exposure at opengl.org
> >>>>> - this also implies we (bf-blender) should get ready to remove ghost
> >>>>> from the Blender cvs... and include it as extern lib (such as jpeg).
> >>>>> - agreed on is to freeze now bf-blender ghost; meaning that 
> >>>>> commits  to
> >>>>> it are not allowed unless it's also done in the official ghost
> >>>>> project.
> >>>>> During the next period, hopefully before the 2.29 release, we can
> >>>>> discuss & decide on how to incorporate the ghost lib.
> >>>>> - Ghost is being ported to BeOS (R5, last official release).
> >>>>
> >>>>
> >>>> is ghost being externalized, and abstracted to the degree that
> >>>> we could put GLUT back in for the hardware that worked MUCH
> >>>> better with it?
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Bf-committers mailing list
> >>>> Bf-committers@blender.org
> >>>> http://www.blender.org/mailman/listinfo/bf-committers
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------- 
> >>> -- 
> >>> -- 
> >>> Ton Roosendaal  Blender Foundation ton@blender.org
> >>> http://www.blender.org
> >>>
> >>> _______________________________________________
> >>> Bf-committers mailing list
> >>> Bf-committers@blender.org
> >>> http://www.blender.org/mailman/listinfo/bf-committers
> >>>
> >>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://www.blender.org/mailman/listinfo/bf-committers
> >>
> >>
> > ------------------------------------------------------------------------ 
> > -- 
> > Ton Roosendaal  Blender Foundation ton@blender.org  
> > http://www.blender.org
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://www.blender.org/mailman/listinfo/bf-committers
> >
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>