But just to check on another posibilty what gfx lib are you using and what machine?
x5000, graphics.library 54.241 (11/16/2017)
But , on the same machine and the same graphics.library, SDL1 didn't make that timer flood. For now iam 99% sure that problem is that unix/SDL_systimer.c (which use usleep()as well), which in SDL1 replaced with our native code (timer/amigaos4/SDL_os4timer.c)
Quote:
One thing to note though, since the opening of timer.device is there to create a timed delay or some such, it's not likely to slow anythig down, unless you are running snoopy or similar....
But looks wrong anyway :) Its just like about 5-10 opens of timer.device in a second.
@TSK Quote:
Is SDL using usleep() and sleep() functions of Newlib ?
Sure, in that unix/SDL_systimer.c it use usleep for os4.
Yeah, SDL2 uses usleep(). If usleep really opens timer.device every time, I think we should a) open a ticket against newlib and b) replace it with custom timer code in SDL2.
EDIT: confirmed to be "usleep issue" by calling usleep 10 times in a row. EDIT2: BZ opened
Edited by Capehill on 2018/2/1 18:12:53 Edited by Capehill on 2018/2/1 18:27:20
Do you know what exactly happen on WinUAE when CompositeTags() is called? Does it return with success or fail? SDL2 should have some serial debug in case CompositeTags() fails. Not sure if serial debug can be easily enabled with WinUAE though.
And why compositing doesn't fallback to native SW rendering?
Please, try to improve the bug reporting. I don't have time to guess what might have happened. What is missing in your report:
- SDL2 SVN revision or git hash - link to failing binary - link to source code - some details what kind of drawing might have been used, like OpenGL or compositing - possible serial logs. You should know by now that SDL2 logs lots of stuff, being still considered as "beta"
If I have about 30 minutes per day for SDL2 / Amiga, I would rather spend that on something useful.
>[SDL] Do you know what exactly happen on WinUAE when CompositeTags() is called?
I know NOTHING about SDL1 or SDL2 running on WinUAE-ppc : I was just saying that PatchCompositeTags will allow them to works if they use Composition...
>on WinUAE when CompositeTags() is called? With latest OS41 update It works (soft rendering) for rectangular compositions else Return an error (triangles compositions used for rotated sprites)
Regarding iconifying, "worry-free" solution would be the best. I think there should be an iconification gadget if window has the normal borders (whenever the controls are enabled).
Regarding iconifying, "worry-free" solution would be the best. I think there should be an iconification gadget if window has the normal borders (whenever the controls are enabled).
Yeah, when there is other gadgets, why not have iconify by default as well, without any needs for specific flags, right:)
Btw, yesterday i tried to enable aos4s timers code in sdl2 (that on from src/timer/amigaos4/) , and while i was able to do it in that "configure" file mess , it seems it also depent on our threading replacement. I.e. as far as i can see, for now in SDL2 we use pthreads, while, we also have in sdl1 : src/thread/amigaos4/ custom threads code. So probably to make os4's custom timing code works, we also need to enable custom threads code as well (and we can get rid of pthreads then as well, which is not bad, less dependencies).
usleep() opening timer.device for every call is not really a bug, it's not an illegal thing to do, nor harmful to the system. You wouldn't even notice if not running snoopy.
But in any case try replacing it with ITimer->MicroDelay()
Regarding usleep, I would have thought that Newlib would have had a timer context for each process. I can accept WONTFIX of course if it works as wanted.
There must be some software that does a crazy amount of tiny usleep calls per second. Perhaps in that kind of scenario problem might become more visible?
SDL1 concurrency code may have some issues. At least testlock and perhaps some other case was problematic (crash when quit by CTRL-C). If you have time and interest, try to find the bug :)
sorry for being unclear in reporting this problem, but I only received information from another user and, by running some tests, I noticed that actually no pixels were displayed. I did not have time to do more extensive tests. I also tried patchcomposite, but the problem remains. I will do more test asap, maybe using sashimi.
But in any case try replacing it with ITimer->MicroDelay()
Please don't. This function busy waits and is not meant to be used as a general purpose wait function.
From the autodoc: Quote:
This function works by polling the system time until the requested number of microseconds have passed. It should therefore be used only if the regular time delay functions of timer.device are not available, and it should be used only for small delays.
@Capehill I know its probably too early, and you are aware yourself how it should work, but i just tested your latest iconification branch , and compile gigalomania game with new sdl2 library, and iconify gadget attached well :) :
(Press open in new tab for fullsize)
Once i press on it, it bring a window with debug words about button being pressed :) So, even if it not ready, it pays of already: no changes need to be done, it just works without any code changes, cool. Thanks !
Btw, seeing code of commits, it looks harder than i hope in begining :) But looks like copy+paste to SDL1 should did the trick.
Iconifying gadget itself is only a minor detail in the picture :)
I am afraid how SDL applications actually react when the native window is closed and re-opened, possibly on a different screen. Problems ahead probably, think OpenGL context and such that are managed by the application.
I am afraid how SDL applications actually react when the native window is closed and re-opened, possibly on a different screen. Problems ahead probably, think OpenGL context and such that are managed by the application.
They will react with something bewteen a grim reaper and small nuclear explosion!
You have to let the application handle the iconification, send it some sdl equivalent of window.classes WMHI_ICONIFY message, becaue you can't know what resources / processes might need to be suspended, whilst the window is closed.
If SDL has an equivalent of that already some apps might be able to take care of it, if it doesn't then the porter will need to handle it with custom code.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
