Winamp Visualisations. Finally :-) (2 Viewers)

[BassFan]

It is done completely wrong and should be re-written

i have be re-written so it work.
Bass_Visualization_Fix

this do nothing with my question of why a thread do nothing and used to many CPU.

greets

 

[tourettes]

It is done completely wrong and should be re-written

i have be re-written so it work.
this do nothing with my question of why a thread do nothing and used to many CPU.

It works, but the current approach (didn't check your code) is completely wrong when GDI and DirectX based content gets mixed.

Quick comment: The proper way would be that the visualization component provides a DirextX texture to the MP Skin Engine which then vill compose the final image on presentation interval (PAL == 50Hz). If vizualisation component is not able to provide a D3D texture on 50 fps rate then it should provide it on 25 fps rate to prevent juddering.

 

[BassFan]

is completely wrong when GDI and DirectX based content gets mixed

properly if it is so
But it's not
because the visualizations are pushed with SetParent in a usercontrol.
and have their own Window
because nothing is mixed with GDI and DirectX

i hope you understand my english.

greets

 

[tourettes]

and have their own Window
because nothing is mixed with GDI and DirectX

This is the issue. Now GDI content gets just drawn over the DirectX based UI and it is not possible to seamlesly integrate the visualization and MP UI. For example if there should be an overlay layer (UI dialog for example) it wont be possible with the current approach - that is why the visualization provider (what ever is used) should provide a D3D texture that the MP Skin Engine can use in the rendering pass. Separate window might work in desktop environent / application but it won't work properly in MP context.

 

[BassFan]

Separate window might work in desktop environent / application but it won't work properly in MP context

it work! why not?
i have tell you that i have a problem with the RenderThread and this is fixed now after 3 Day debugging
Milk2 run in Fullscreen with resolution of 1920x1200 only 3 > max 5%
and go to 0 after the Visualization Window are hidden..

It now works as it should
no people can make it better as the owner (developer) of the Visualization Wrapper

but it is not on high priority

i think many people wait for a working Visualization for many years.
And i think is time now!


greets

 

[Sebastiii]

I'm lost, you mean you extend your fix by reduce CPU Usage ? (so another patch is coming ?

 

[BassFan]

I'm lost, you mean you extend your fix by reduce CPU Usage ? (so another patch is coming ?

Yes!
while.. do in a thread without sleep a little is a bad idea
i will upload new TestArchive and a new Patch.File

Milk2 = 3-5%
BassBox = 1- 2%
Sonique = more resolution more CPU go to 0 after Window is hidden

greets

 

[tourettes]

no people can make it better as the owner (developer) of the Visualization Wrapper

Exactly, I was just stating how bad the current MP1 implementation for the vizualization is (please see the attachement which shows the visial aspect - technical side is even far more worse ).

As stated earlier the whole visualization in MP1 should be rewritten - preferrably in such way that D3D textures are used for the data passing, that way the visualisation provider can render directly to a D3D surface (using pixel shaders etc) and then MP Skin Engine can just compose UI. It would be the most efficient way to handle the visualization and also it would give really good ability to use modern GPU resources for the actual visualization. 2nd option would to allow bitmaps to be trasnferred between MP Skin Engine and visualization provider, but that is already pretty horrible solution (even thou better than current) and shouldn't be implemented.

 

[tourettes]

while.. do in a thread without sleep a little is a bad idea

If it about frame scheduling or drawing... sleep is not a good idea. Much better way is to waut for the v-sync or let DirectX (or similar Windows API) to handle the frame waits. Sleep is just an ugly way of scheduling anything drawing related.

If it is about some polling (yuck! ) then better to replace it with a timer. Or even better, to get rid of the polling architecture and use something event based.

 

[BassFan]

you can nothing draw on your overlay why..
all plugin create internal a own window for rendering (also i have written my own Winamp Plugin in OpenGL)
you can not draw Sonique Visualization (GDI) on a DirectX Surface
and you can not draw Bassbox Plugin (OpenGL) on your overlay.

this is a good idea when create visualization directly for MP so you can draw in the own Surface in MP directly without overlay window.
I think no people has time and do this on this time..

sleep is not a good idea.

one ms is good enough no more no less
that's enough to give the thread a little time

Thread.Sleep(1);

greets