Slower gadget & canvas resizing...

Hello,

I've made my own software. With previous version of MaxGui, the resizing of my window works fine : all the canvas and gadget were redrawn fast and immediately when I resize the window.

But now the latest version of MaxGui (maxgui.ex) from subversion, the refresh of the canvas is slower and not good.
When I resize my window : the canvas is not resized immediately and artifact or black color is displayed on the extended zone before the canvas is resized.

I have tested it on Vista and XP, the problem is the same.

Despite it is written on the doc of MaxGui.Win32MaxGuiEx, resizing is really slower than previous...

I hope a solution will be found quickly...

Thanks.

Hi,

How many gadgets does your window have on it? Do you have any group panels or tabbers? Is it slow when resizing using the window's size handles, or when calling SetGadgetShape()? Can you post a screenshot?

I've tried to replicate your problem to no avail as the older module seems to resize slower in nearly every case, however remember that the new module includes pseudo-transparent gadgets which although look better, involve slightly more code to redraw...

If your problem is severely affecting your project, you are welcome to send me the source code (e-mail address in profile) and I'll gladly have a look into a fix for you.

If anything, the new module should atleast mean less flicker and if you are reluctant to send me the source, then a compiled EXE would be better than nothing...

Cheers!

Hi SebHoll,

Thank to try to help me.
My software is shareware and complex, i can't send you the source code, sorry.
I will send you the previous and new exe file.

Thanks.

SebHoll,

I can't send you the exe file by email, your email seems to not work yet...
Please can you give me a way to send the exe file.

Thanks

@ Source: OK, I'll have a go, but it will limit my testing severely. If you can make a short code example that demonstrates the problem, that would be better.

@ EXEs: You have e-mail!

Not sure if it helps but I ran the code from here on my T61 and there was a delay resizing the canvas while on my 7600GT there was none. My desktop has latest SVN version of MaxGUI while I don't know about my laptop.

Coconut, what Gfx card and driver + DirectX do you use?

I would notice than previous version of MaxGui works fine on my system :
Intel Dual Core 4400
2 Go of RAM
Geforce 8600 GTS
DirectX 9.0c + 10.0
I don't think that the problem is directx or gfx card.
My system is fast enough...

Sebholl, I haven't a brother, sorry, i'm a french developer.

Ahh, well - nevermind then...


You're right there...

Still haven't received an e-mail though, yet...

Oh, received your e-mail today and I see your problem...

However, there is something strange going on with the way *your* gadgets are being sized... Are you manually calling SetGadgetShape() on your panels in response to EVENT_WINDOWSIZE?

I knocked up this quick benchmark program to time each module when it is resized with 48 canvases and if anything it shows that the new MaxGUI.Win32MaxGUIEx is slightly faster. Try it for yourself...

SuperStrict

'Framework MaxGUI.Win32MaxGUI
Framework MaxGUI.Win32MaxGUIEx
Import BRL.Random
Import BRL.D3D7Max2D

Const COUNT% = 5

SeedRnd MilliSecs()

Global wndMain:TGadget = CreateWindow("Test Window", 100, 100, 400, 300, Null, WINDOW_TITLEBAR|WINDOW_CLIENTCOORDS|WINDOW_STATUS|WINDOW_RESIZABLE)
	
	Global canvasArray:TGadget[][]
	
	For Local x% = 0 Until ClientWidth(wndMain)/50
		canvasArray = canvasArray[..x+1]
		canvasArray[x] = New TGadget[ClientHeight(wndMain)/50]
		For Local y% = 0 Until ClientHeight(wndMain)/50
			canvasArray[x][y] = CreateCanvas(x*50,y*50,50,50,wndMain);SetGadgetLayout(canvasArray[x][y],EDGE_RELATIVE,EDGE_RELATIVE,EDGE_RELATIVE,EDGE_RELATIVE)
		Next
	Next
	
	ColourizeGadgetArray( canvasArray )
	
	PollSystem()
	
AddHook EmitEventHook, eventHook

Local tmpTotal%

For Local i% = 0 Until COUNT
	Local tmpTime% = MilliSecs()
	SetGadgetShape(wndMain, 100,100,800,600)
	PollSystem();tmpTotal:+(MilliSecs()-tmpTime)
	Print (MilliSecs()-tmpTime) + "ms";PollSystem()
	tmpTime% = MilliSecs()
	SetGadgetShape(wndMain, 100,100,400,300)
	PollSystem();tmpTotal:+(MilliSecs()-tmpTime)
	Print (MilliSecs()-tmpTime) + "ms";PollSystem()
Next

If count Then Print "Resized " + (COUNT*2) + " times, taking an average of " + (tmpTotal/(COUNT*2)) + "ms."

Repeat;WaitSystem();Forever

Function ColourizeGadgetArray( pArray:TGadget[][] )
	
	For Local tmpArray:TGadget[] = EachIn pArray
		For Local tmpGadget:TGadget = EachIn tmpArray
			RepaintCanvas(tmpGadget)
		Next
	Next
	
EndFunction

Function RepaintCanvas( pCanvas:TGadget )
	
	SetGraphics CanvasGraphics(pCanvas)
	SetViewport( 0,0,ClientWidth(pCanvas), ClientHeight(pCanvas) )
	SetClsColor( Rand(0,255), Rand(0,255), Rand(0,255))
	Cls;Flip

EndFunction


Function eventHook:Object( pID%, pData:Object, pContext:Object )
	
	Local pEvent:TEvent = TEvent(pData)
	If Not pEvent Then Return pData
	
	'SetStatusText wndMain, pEvent.ToString()
	
	Select pEvent.id
		
		Case EVENT_GADGETPAINT;RepaintCanvas( TGAdget(pEvent.source) )
		Case EVENT_APPTERMINATE, EVENT_WINDOWCLOSE;End
		
	EndSelect
	
	Return Null
	
EndFunction

Also, I know this is irrelevant, but I noticed that you are using tool windows for message boxes... Is there a reason why you aren't using the standard OS message boxes (available using the Notify(), Proceed() and Confirm() commands)? It looks a bit unexpected, that's all...

Anyway, there isn't much I can do until I learn a lot more about how you are drawing your canvases, and how you are resizing your gadgets...

ok,Sebholl.
I will look at your code.
Yes, I manually call SetGadgetshape.

Thanks for your help.

From my experience SetGadgetShape is deadly slow and buggy.

Use SetGadgetLayout(gadget:TGadget,Left,Right,Top,Bottom) instead and I'm sure the redrawing problems will be gone forever.

Exactly! Coconut76: this is why your resizing will be slower. MaxGUI.Win32MaxGUIEx is highly optimized in repositioning gadgets internally using SetGadgetLayout upon gadget resize - calling SetGadgetShape() is painfully slow in comparison as the OS to redraw parts of the parent gadget and the gadget itself immediately, unlike the internal MaxGUI resizing MaxGUI mechanisms which cache the drawing so that it is all performed once all the gadgets have been relocated.

SebHoll,

I've just try your example but it is not fast enough on my pc.
The problem seems to be the same as in my software, when I enlarge the windows, the canvas are not resized immediately...

It takes :
Resized 10 times, taking an average of 883ms.

Are you a an idea about that ?

I've sent you Sebholl a screenshot of the problem...

I've just try to replace SetGadgetShape by SetGadgetlayout.
But it doesn't change the speed of resizing canvas :-(

And SetGadgetLayout doesn't work as I want for my software. Some gagdet are not very well resized...

But my problem is not resolved at all.
Before with previous version of MaxGui, my software was fast enough when I enlarge the window : now it is much much slower...

I have no time to try to find what it is wrong on Maxgui between the new version and the old.
I'm a little disappointed because it blocks my development on my software.

Normally it should be faster but not slower.
I hope someone will find the problem...

Thanks for all.

So are you saying that even my canvas example resizes slower using the new MaxGUI driver compared with the old? This is strange as on all my PCs the new module was faster. Hhhhhhmmmmmm....

I don't know for your example because I don't remove the new MaxGui (or onyl if it is the only way to solve this problem ...).

But the bug is always presents : you can see it on the screenshot I sent you : the blank area in the right of the canavs due to the delay for redrawing the canvas.

I can't beleive that my gfx card is not fast enough to redraw this simple canvas immediately... especially if it was faster before.

If you can say me what you modify in MaxGui that can produce this effect... or even correct it !

It will fine.

I have tested and retested the bug is always present.
I'm little tired to try to find a solution...
I hope this bug will be resolved quickly.
Thank in advance.

I'm finding it hard trying to understand your responses...


I've spent a good few hours trying to optimise it further, but all my tests show that using:

Import MaxGUI.Win32MaxGUI<u>Ex</u>

is faster than using the old legacy module...

Import MaxGUI.Win32MaxGUI

... in all cases. Remember, we are resizing and repainting 48 canvases individually in this example (each waiting for the vertical blank) and so it's actually quite fast at what it is. Without the source, it's near impossible for me to help futher as there is something particular about your set-up which is key to this... If you can't send me the source, or a decent code example, then I can't really be of any further help, sorry... :-(

(Resized 100 times, taking an average of 75ms on my PC.)

Wow! That's lightning fast! Is that 75ms per canvas, or per complete resize? If it's the latter, then your PC is running circles around my Core 2 Duo laptop (averaging at about 900ms per complete resize [or in other words, as there are 48 canvases being resized, 19ms per canvas]).

Edit:

@coconut76: is it not possible for you to just send me just your GUI code, and leave out all the other stuff to do with loading/rendering graphics if you don't want to trust me with the entire source?

However I should mention that other MaxGUI users have sent me their source code in the past and I haven't run off and sold their hard work for millions - remember, I'm a coder myself and I know how terrible it would be for that to happen. When the new Windows module was first introduced, Grisu was having problems and he sent me the source to his DFA archive where all know problems have now been ironed out.

Also I compile Grisu's source as a final test before sending out public releases of the latest MaxGUI changes to see if there are any new problems introduced. Still, I'm not going to blame you if you are hesitant to do so... It's just I'm not sure I can be of any more help.

SebHoll,

Thank to try to help me.
In fact, my problem is very simple :
- with a previous version (i don't know exactly the version but it was with bmax 1.24,i think ) of MaxGui (few months ago) which was integrated in brl/pub mod, the canvas of my window was increased instantaneously without black blank area in the extended zone.

Now there is this disgracious black extended zone before the canvas is redrawn. (due to the delay of redrawing)
I want to specify that I haven't modified the source code, just recompile and have this problem. The first time I thought it was a bug in my code but i realized that it was MaxGui changed. So the bug wasn't in my code...

And I saw the same problem with your example only the extended zone is gray instead of black !
So setgadgetlayout doesn't resolve the problem ,it is the same than setgadgetshape.

My program has more than 10000 lines of code, it isn't easy to send only Gui code...

I will look at that.

Do you have any "funny" tools installed like Window Blinds or the like which highly interfer with the OS gadget repaint handling?

no of course.
No special tools installed just Vista or XP system alone without particular tools.
I have optimize my code to speed up the refresh but the black area is still here and I have no influence on it.

So are you saying that you are experiencing the same lag both in the new Windows MaxGUI driver (MaxGUI.Win32MaxGUIEx) and the legacy Windows MaxGUI driver (MaxGUI.Win32MaxGUI), i.e. this problem isn't specific to the new module? If this is the case, I could really do with knowing the exact version of the old Windows module that resized appropriately, and the version at which it slowed down. My original understanding that this was *only* evident in the new MaxGUI.Win32MaxGUIEx module...


I have a tonne of exams approaching in a few weeks so my very limited free coding time is completely wiped out now that I'm revising. As such, I don't have time to download and test each MaxGUI release myself (and even if I did, I don't have your problematic source code). As such, if you want me to look into this, I'll need some help.

I have tested with MaxGui.Win32MaxGui and the problem doesn't appear, the redrawing of canvas is much more faster.
The black area is not visible...
The bug disappear with the legacy maxgui driver !

So the bug is in new module MaxGui.Win32MaxGuiEx !

But for your example the problem is approximetaly the same : gray area appears in both cases.
and speed are - 890 ms and 880 ms for legacy and new module so no speed up....

So you have well understanding , the bug is in the new module.

OK, so it's just with the new driver.

Just to convince you that MaxGUI resizing is faster with the new Windows module, have a look at one of my internal test apps:

MaxGUI Resize Test (Warning: Will Draw 500 Gadgets)

Not only does the new Windows module draw the window better (try moving your mouse over the buttons in Win32MaxGUI.exe - yuk!), it resizes faster too! This is definitely specific to your code.

For those who want the source code:

SuperStrict

Framework MaxGUI.Win32MaxGUIEx
Import BRL.EventQueue
Import BRL.Random
'Import "xpmanifest.o"

SeedRnd MilliSecs()

Const TOTALGADGET% = 500	'Let's go extreme

AppTitle = "Drawing " + TOTALGADGET + " Gadgets"

Global wndMain:TGadget = CreateWindow(AppTitle,100,100,400,300,Null,WINDOW_TITLEBAR|WINDOW_RESIZABLE)

Local tmpParent:TGadget = wndMain

For Local i% = 1 To TOTALGADGET
	Local tmpGadget:TGadget = CreateButton(i,Rand(0,400),Rand(0,300),Rand(20,150),30,tmpParent,i Mod 4 )
	SetGadgetLayout tmpGadget, Rand(0,2), Rand(0,2), Rand(0,2), Rand(0,2)
	SetGadgetColor tmpGadget, Rand(0,255), Rand(0,255), Rand(0,255)
Next

Repeat

	WaitEvent()
	Print CurrentEvent.ToString()
	
	Select EventID()
	
		Case EVENT_WINDOWCLOSE, EVENT_APPTERMINATE;End
		
	EndSelect
	
Forever

Commenting out the SetGadgetColor() command will make the new module a bit slower, but it is still faster than the older module (this is because of the new faked gadget transparency in the new module if no background colour is set).


As all my code example can't reproduce your bug, than there isn't much else I can do unless I can test with your problematic code. Sorry.

Ok for your MaxGui Resize Test : it is much more faster with new module.
But not with your previous example : it is around the same speed.
I use SetGadgetshape because it is more adapted to my program than SetGadgetLayout.

I will try to send you a code example when I have time because I need to finish my new program version (with the bug unformately...)

That would therefore suggest that this is more to do with the fact that MaxGUI Canvases and them being different from normal gadgets in as much that they are hardware accelerated graphics contexts being displayed in a software rendered environment (the Windows GUI window). I have little understanding on how this all works internally when Flip is called, but this is all up to the Max2D driver (not MaxGUI).

Anyway, you said yourself that even with my previous canvas example, the new module had around the same speed as the old module, so I suppose I'll have to wait for that code example.

Finally I have found that the problems seems to be with the command SetGadgetLayout because when I set :

SetGadgetLayout canvas_plan, EDGE_RELATIVE, 0, EDGE_RELATIVE, 0

The black area is replaced by gray area, all other settings of this command will generate more bugs.

The only thing, I do :
When an "event_gagdetpaint" for the canvas is sent, I reshape my canvas with setgagdetshape and redraw it.

With the old module Maxgui, all is fine and fast.
With the new one, redraw is slower and black or gray area appears.

Finally, I will use the old version because I have lost a lot of time to resolve this bug.
I'm a little tired to try to resolve this bug...

I hope next version will be better...

OK, so can you make me a short code example that shows this behaviour in a few lines that I can use to try and debug the problem. I only do programming in my freetime (what little of it I have nowadays) and the few code examples I have tried to write to show your problem, don't.


I still don't understand what you mean be swapping black/grey areas - a runnable code example would demonstrate it perfectly.


Responding to the EVENT_GADGETPAINT event should not involve repositioning the gadget - I'm surprised you don't get an infinite drawing loop. Surely there's a better place to resize it!!!


I'm sorry about that - but if you could have made a runnable code example in that time, I'd be in a far better position to help.


So you keep saying!!!


UNLIKELY WITHOUT A SHORT CODE EXAMPLE! :-)

Note to self: Ok, Seb now deep breath in... And relax... If coconut76 is fine using the old module, then so be it...

coconut76: I may have asked this before but are you using event hooks or an event queue?

I use an event hook.
I have made a mistake, I only redraw my canvas when EVENTGADGET_PAINT is sent , not reshape. Sorry ;-)

I only reshape when Window is resized.

For gray areas, your example creates this bug !

I wil lsend you an example next week.
I'm too busy now.

I seem to have the same problem, it seem's to all work fine until the width it to wide or the height is to high


I have 1280x1024 screen
with leadwerks engine (opengl I believe)

And setting it to a maximum window is very ugly.

It is very annoying.

Ok, just tried something
It seems when my task bar is hidden everything is fine.

Yep, just tried it again, and when the Windows Vista 64 bit task bar is showing, it runs real slow, and when the task bar is hidden, it is real smooth.

The window also has to be stretched big and taskbar showing=problems
But if taskbar is showing and window is small, everything is still fine.

When running fine, Cpu process for MaxGui program is usually around 0-3
When problem occurs,Cpu process for MaxGui program is around 27-30

When taskbar is hidden everything is fine.

Taskbar is hurting MaxGUI perfomance when MaxGUI program is almost full screen.
Is there a Hidetaskbar and Showtaskbar command for BlitzMax.

Only one has to be almost fully stretched either width or height, and the other has to be at least almost half the screen, with task bar showing.


Try changing your properties for your task bar and give it a test.
Run Task Manager and view the Processes, CPU changes.

It seems to be more when a 2d graphics is overlaying the Maxgui Window, including if sidebar was overlapping, stardock,Clicking on start and the Menu overlays the Maxgui window

Very Strange Problem.

Yes very strange and annoying problem.
I have lost a lot of time to try to resolve it without succes 8 months ago !
So I have returned to old version of MaxGui not MaxGuiEx.
I'm very disappointed with Maxgui but now my project used it and I can't return back !
I hope this bug will be resolved yet...