Hey Jus,
Glad to hear the issue is improved without using OpenGL.
A slight correction, the writing of JPG's to the filesystem is simply for
debugging purposes (so you can see what the tiles are supposed to look like,
independent of how they are rendered in Mixxx). The tiles are held in memory
normally, and do not need to be written to the filesystem.
As for the gradient background, I agree that the background should be more
the realm of the skin designer, but when using OpenGL, it wasn't possible to
make it transparent so that the skin beneath it showed. Without using
OpenGL, this should not be a problem.
Best,
RJ
On Wed, Apr 7, 2010 at 2:24 PM, jus <[email protected]> wrote:
> Hello,
> I noticed no big difference on Intel GMA based Macbook, but a significant
> change on Nvidia Geforce 9400M based Macbook pro.
> With this patch Mixxx 1.8.0b2-pre is back to the CPU utilization of Mixxx
> 1.7.1 and usable again on Mac. Good work!
>
> For all numbers please see attached file.
>
> jus
>
>
> PS.
> Mixxx writes the waveform tiles as jpg files (numbered in increments of 300
> ;-) straight to the install dir (at least on OSX),
> so you get 0.jpg, 300.jpg, .....16200.jpg etc. all over the place.
>
> PPS.
> If you are going to change the waveform view for saving CPU, why not dump
> the gradient waveform background too?
>
> On 6 Apr 2010, at 08:15, Albert Santoni wrote:
>
> Hi guys,
>
> About a month ago, RJ slapped together a "tiling" waveform renderer
> that pre-renders the waveform in chunks to disk. Displaying the
> waveform then becomes reading a bunch of saved images and just
> blitting them to various positions. I believe the current waveform
> renderer that we have in 1.7 and 1.8/trunk draws directly on the
> screen, but because we're using OpenGL, it's normally very fast.
>
> However, we've got OpenGL problems all over the place. For some
> people, Mixxx's waveform views are corrupt when used with compositing
> window managers and common NVIDIA and ATI videocards. For other
> people, the waveform is inexplicably taxing - Their videocards report
> that they have direct rendering enabled, but the waveform eats up CPU
> as if that weren't the case. These problems affect at least Linux and
> OS X, and I wouldn't be surprised if there were cases where Windows
> users are suffering performance problems or artifacts too.
>
> Anyways, some of the guys and I spent some time trying to find various
> fixes and workarounds to our problems. I was trying to solve
> corruption of the first player on Linux, which I thought had something
> to do with X not letting us do real direct rendering. RJ originally
> wrote his tiling renderer code to see if he could solve a performance
> problem on OS X that Jus had, but it didn't seem to make a difference.
> However, after about a few hours of trying random things, I decided to
> try the tiling renderer with our regular QWidget-based waveform
> viewer, not our OpenGL one.
>
> The result? I have the exact same performance on my desktop Linux
> machine (Core 2 Duo E8500, ATI HD4850) with OpenGL/trunk as I do
> without OpenGL using the new tiling renderer. That's very good news.
> (For reference, trunk with the non-GL widget has very high CPU usage,
> something like > 75%, while I get about 16% with trunk and with my
> patch for features_waveform.)
>
> I think we might have an escape plan from these increasing number of
> problems with OpenGL - ie. Don't use it. :)
>
> If anyone wants to play with this and see if it has any impact on
> performance, I've attached a patch that should be applied to the
> features_waveform branch on Launchpad. There's still some rough edges
> with the code, so please feel free to dig in and fix things that are
> broken! (eg. the beat markers sliding when the pitch is changed.)
>
> Thanks,
> Albert
> <no-glwidget-reset-tiles.patch>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
>
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
