Fixed (another side-effect of removing libauto, and forgot to open/close layers.library/iface).
Thanks, so i removed the point 1 from the list
Quote:
In meantime i just do the same iconify as it happens from gadget for our port, so it all will be same for both iconifies and comment out hiding of window.
Point 2 also removed !
Quote:
Horray ! Thanks to Joerg, white stripes in the p96_overlay fullscreen mode fixed !
As both versions share exactly the same p96_pip driver we have of course the same problem with MUI MPlayer and in afxgroup's one No problem with SDL and cgx_wpa (in MUI MPlayer), so in end p96_pip seems the only one with this problem
At the time Fab talked about a possible lacking of multibuffering support in OS4, but if it works in both SDL and cgx_wpa drivers, then the only possibility imho is a bug in our current p96_pip implementation..
Joerg as you are working on and if you have time. can you check it ?
and that osd flick problem for sure not high priority, if it will specially mean bunch of new code
Yes but you didn't consider the subtitles ! Volume (or progressing) sliders for sure can be low as priority, but reading an entire movie with subtitle might be problematic with such flickering
Aniway crossing finger for a (later) easy solution
@samo Liveforit imho right, if it something about buffering, it will slow down the speed probably, as any buffering mean doing something in between which before wasn't
You need to buffer the overlay bitmap, in order to remove the flicker. The flickering is because you are seeing what is being drawn.
Are you talking about flickering of the OSD? Or flickering of the movie?
It sounds like OSD is currently implemented by rendering text over the top of the video frames. That's a poor way of doing it, because then you have to render to a YUV bitmap (which can be complicated), and do so every frame. Instead, you should replace the window's backfill hook, and render the OSD over the top of the colour-keyed background. That way, they overlay hardware takes care of showing the video behind the OSD. The added bonus is that the OSD doesn't have to be rerendered every frame.
Your backfill hook would work like this: - fill the parts of the window where the video should appear with the colur-key colour (usually magenta, but you can set it yourself to anything you fancy) - render the OSD
If this is confusing, remember that the video frames are overlaid over the window itself using chroma-keying (a.k.a., colour-keying). The window has its own bitmap and/or region on-screen. The video frame's pixels only show where the bitmap is the colour of the chroma-key. All other pixels will be the colour of the window's own bitmap.
Liveforit imho right, if it something about buffering, it will slow down the speed probably, as any buffering mean doing something in between which before wasn't
its a bitmap so drawn into the that, and then the bitmap is painted on window at page flip.
When you paint into the overlay windows bitmap its displayed immediately, this way you see it flickers.
If you make buffer for the overlay, then you will need to copy the buffer to overlay window, unless there is some double buffer feature in display overlay window I do not know about, this going to be cost some cpu load.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Hans way of working to solve issue might work, will require special code. It might be possible, have not tried.
What is suggested as work around is that parts of overlay is made transparent, so that you can see the window background color instead. This will prevent over drawing the overlay.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
If you make buffer for the overlay, then you will need to copy the buffer to overlay window, unless there is some double buffer feature in display overlay window I do not know about, this going to be cost some cpu load.
AFAIK, yes, overlay supports double-buffering. Don't ask me how, as I've never used it myself. I don't think that the details are in the current Picasso96 autodocs, so have a look in the header files.
Where can i find the cd file to translate it to german? Why don`t you use AISS for the gui? I think it will look more like AmigaOs Why can`t i save settings like Volume Gain? I have to set it everytime again
Where can i find the cd file to translate it to german?
Nowhere, program doesn't support locale i think
Quote:
Why don`t you use AISS for the gui? I think it will look more like AmigaOs
Current port uses the same buttons of SMPlayer on Linux, but graphical buttons are separeted, so if you want you can make a skin
Quote:
Why can`t i save settings like Volume Gain?
Same problem, some options still not saved after closing (i for example use mostly 16:10 settings for some video, but the settings will not be mantained at exit)
- registered as application via application.library
- screenblankers based on real os4 screenblanker engine are enabled/disabled when need (i.e. they disables only when video actually plays, if it paused, blanker enables back. If no video play (but gui in run), or just audio, then no disabling: in other words logical and as on all oses in all players). Done that for all output drivers which i have currently: p96_pip, cgx_wpa and sdl. That all was easy as Fab's code-logic already was here, all i do its add necessary os4 parts + add the same logic to p96_pip and sdl drivers (as cgx_wpa originally have it too).
And as there is now application library in use, i can now easy add ringhio messages as well, just when (if at all) ?
Perhaps "job done": if mplayer is outputting png files, wav files, dumping a stream for a long time or whatever batch functionality it has. IOW when mplayer returns (not sure how it works with GUI).
I'd just like to say how pleased I am to see work begin on updating mui-mplayer/gui so soon after the release of the v1.0 Radeon Driver :) It does make me wonder what next needs updating s/w wise.
@Hans - I wonder whether the driver had that tech implemented which made it easier to do screen capturing (video)?