I try to use the slideshow function like an background effect but after the effect the transparency labels aren't transparent
And the effect is very slow in my emulator
How can I do it faster?
Here is my code:
Code:
Public Sub formFadeShow (ParentForm,TargetForm) FadedForm = "Main."&TargetForm imgTargetBg = "Main.img"&TargetForm&"Bg" CapFade.New1 CapFade.ControlCapture("Main."&ParentForm,0,0,240,320) Control(imgTargetBg,Image).Image = CapFade.Image imgCapture.Image = CapFade.Image BmExFade1.New3(imgCapture.Image) BmExFade2.New2(imgFadeBg.Width,imgFadeBg.Height) DrawExFade.New2(BmExFade2.Value) DrawExFade.Clear(cBlack) ShowFade.New1 ShowFade.NewTransition(BmExFade1.Value,BmExFade2.Value,cGray,True) timFadeIn.Interval = Interval timFadeIn.Enabled = True Control("Main."&TargetForm,Form).Show End Sub
Sub timFadeIn_Tick Percent = Percent + Increment Control(imgTargetBg,Image).Image = ShowFade.Fade(Percent) If Percent >= FadeContrast Then timFadeIn.Enabled = False Percent = 0 EndIf End Sub
If by emulator you mean the Microsoft device emulator running on the desktop then yes, it is slow and no, you can't get it to go faster.
You should be calling EndTransition after the fade has finished.
I am not entirely certain what your controls and objects are. It is always best to post a small sbp file that will run so we can see the problem. Otherwise we just waste time trying to guess what you are doing.
In this case my guess is that "Main.img"&TargetForm&"Bg" is an Image control and things don't work the way you think. A transparent label draws itself using the image of the form or panel on which it is located. remove the image control and try setting Form.Image with the fade. I don't know if that will work, if you had posted a demo of the problem I would probably have tried a quick mod to test it but I'm not going to waste time trying to re-implement what I think you are doing.
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
Concerning AutoScale.
I had the feeling, on my htc Touch HD, for quite some time, that the refreshing of the screen with AutoScale and the ImageLibEx is very slow on a Form's forelayer, but had never made any comparisons yet. But now this has been done.
Attached several source codes showing the problem:
- TestMouseMove with
drwMainF.RefreshForm2("frmMain",rectDest.Value)
very slow
- TestMouseMove1 with frmMain.Refresh faster but still slow
- TestMouseMoveVGA, true Vga, with frmMain.Refresh, much faster !
I'm about thinking that I will abandon using AutoScale, directly program for VGA, and change the dimensions of the controls and fonts to QVGA.
This question is also open for the future, would the standard screen size be VGA and have an AutoScale for 'older' QVGA screens, or still remain with the standard QVGA screen and AutoScale to VGA ?
There is also a 'strange' need for the destination rectangle definition with AutoScale for the device if the x and y coordinates are different to ZERO.
I am a bit surprised that there is a difference between DrawerEx.RefreshForm2 and Form.Refresh as they both do much the same thing, they mark an area of the form invalid and so force a repaint of the form. It is the repainting of the Form that takes the time, not the invalidation. None of the methods in ImageLibEx do any extra work when AutoScaled so the performance hit is not in the library. It may be that callling Refresh on the form forces an immediate call directly to repaint whereas invalidating and then repainting an area may have to go via messages to the application message loop and so may be actually be slower - but I don't know about those internal implementation details. I would just use whatever is fastest
An AutoScaled Form still has QVGA sized bitmaps internally and on a repaint they are stretched to fit the VGA screen making the VGA image a bit "fuzzy". I guess this stretching is where the performance penalty over true VGA is.
Have you tried NativeImage and NativeFormImage from the ControlsExDevice library with AutoScale? They should give you the benefits of AutoScaling the controls but let you control the graphics yourself. I would expect their performance to be the same whether AutoScaled or not. In this case using Form.Refresh avoids some confusion over the area to invalidate (described in the help) and as you noted may even be faster.
Quote:
There is also a 'strange' need for the destination rectangle definition with AutoScale for the device if the x and y coordinates are different to ZERO.
Are you referring to the use of the Rectangle in RefreshForm2? As I said above ImageLibEx does no AutoScale processing so the invalidated area is defined in screen co-ordinates not in notional QVGA co-ordinates. I would however expect to use -
Your code includes an unnecessary area to top and left of the required rectangle - but as Form.Refresh seems quicker perhaps this is an academic point.
__________________
Sorry, but I don't answer questions by PM or email.
Please post your queries in the forum.
Coming back to the rectangle definition.
For copying a partial image on the screen.
When running the attached program, on the device AutoScale compiled, the graphic is not at the right place with:
I am afraid that you are confusing things by using the same Rectangle for drawing as for refreshing. Replace all the drwMain.RefreshForm2 with frmMain.Refresh and remove all the ScreenScaleX and ScreenScaleY scaling from rectDest and you will find it works fine when AutoScaled. The drawing rectangle needs to be specified in QVGA co-ordinates because it is drawing on a QVGA sized bitmap in the form - this is the whole point of AutoScale, it uses QVGA co-ordinates. The refresh rectangle needs to be specified in physical screen co-ordinates because it needs to invalidate the actual area drawn on the screen.
Thanks for a wonderful and powerful library. I have rewritten my CAD program using your library and will post it soon on the forum.
Just one thing. Is it please possile to add a function to draw an arc by defining three points on the arc? How about defining one's own line types i.e. a fenceline, etc.