The idea was to merge them later with ffmpeg or other external tool
It kinds of work but current fps is around 2 !!! So not really usable
The speed issue is related to PNG.
So either the code to store pixels data must be optimized. Or maybe it misses some MT loves :)
Alwawys the same name and uppercase
It was useful on the past to reduce compilation time but there is
less plugins now and ccache just does the job fine.
Currently colclip uses 2 passes to wrap the output of blending unit
However some blending mode are only a plain copy (of 0 or Cs or Cd).
So no overflow of [0:255], no need to wrap it
Note: I saw those cases in GoW.
The Restore-Defaults button and the Presets checkbox are inherently conflicting
since both of them apply (different) sets of values to the speed hacks, however
the Preset also applies values to other panels.
Now the relation between the Defaults button and Preset is consistent with
other panels (EE/VU) where Defaults already got disabled when Presets is used.
Before this patch (and also before the previous one which fixed the locking),
clicking restore-defaults while Presets was checked resulted in incorrect state
where Preset is checked but the speed hacks are both unlocked and also didn't
necessarily match the selected preset. Now this can't happen.
When speed hacks are disabled, clicking Apply should keep the panel grayed-out,
but it didn't before (though it was still correctly locked/unmodifyable).
With this patch it also looks correctly grayed out.
It's not clear if it's a wxWidgets issue or pcsx2 issue since with wxWidgets 3
there doesn't seem to be an issue (see posts at issue #543).
Regardless, this patch makes a cleaner separation between widgets values
([un]checked etc) and widgets states - lock(grayed-out)/unlocked.
The patch only modifies when widgets are grayed and should not affect the actual
values (therefore should not change the behavior other than visuals), but do
keep an eye for weird behavior since this is sensitive code.
Should fix#543
Persistent is slower (at least on my gs dump) because data is put
in host instead of the video memory
I don't understand why upload the data directly to the video memory
is faster