Hello,

in my current project, I need a marquee.
I adapted the component from here:

http://forum.lazarus.freepascal.org/index.php?topic=24646.0

which is a descendant of a TCustomLabel using a timer to move the text position.
I have several problems with it:

- it is very cpu intensive (I have to put it over a picture, so the invalidate will also force the repainting of the bitmap I guess)

- the minimum timer interval is 10ms, and even that it's not guaranteed (the resolution on windows is around 15ms and I got a very different speed of the label using 10ms under virtualized windows xp and a real windows 7 machine)

- with such a low value (10ms) sometimes the application gets bogged down, specifically it cannot process the modal dialog I use to shut down the application.

- I solved the flickering by setting DoubleBuffered to the containing widget (a TPageControl), but, again, I think that takes its toll on cpu usage.

I tried to use a thread (with synchronize) instead of a ttimer to obtain a lower interval, but that only compounds the problems.

For the time being, I'm using 50ms and change the number of pixels to change the speed, however if I scroll more than 2 pixels every 50ms the scrolling isn't smooth enough, but the required speed should be 6 or 7 pixels, and that's very unpleasant to the eye.

Any suggestion?

If I were you I used BGRABitmap or Codebot,they have good text option and you can made a simple one easily,it will be fast,light and beautiful.

Regards,
Ara

Luca Olivetti wrote

- it is very cpu intensive (I have to put it over a picture, so the invalidate will also force the repainting of the bitmap I guess)

The only cure for this is using the graphic processor: only once create a wide pixel array from the text and then use Direct X (Open GL or similar API) to display part of the text "behind" in a rectangle.

What you are trying to do is a multimedia application and hence "soft realtime". This can't decently be done with "normal" desktop-Type paradigms.

- I solved the flickering by setting DoubleBuffered to the containing widget (a TPageControl), but, again, I think that takes its toll on cpu usage.

see above.

I tried to use a thread (with synchronize) instead of a ttimer to obtain a lower interval, but that only compounds the problems.

Obviously

Any suggestion

A thing that we (company) do for a similar application (moving text "behind" a rectangle) is programming the "movie" in Adobe Flash and have the flash player show it on the screen (multiple instances). Works great !

A new development supposedly should avoid Flash (as support for same is dying out) and use HTML4 instead.

-Michael

El 10/11/15 a les 12:36, Aradeonas ha escrit:

If I were you I used BGRABitmap or Codebot,they have good text option and you can made a simple one easily,it will be fast,light and beautiful.

I guess codebot needs a newer fpc, it doesn't compile with 2.6.4. I'm following the tutorials for BGRABitmap to see if it's easy enough to add it to my project.

Bye

Yes for codebot you can use Trunk version or easily get nigh version from GetLazarus website.

Regards,
Ara

Luca Olivetti wrote

I guess codebot needs a newer fpc, it doesn't compile with 2.6.4.

You can also take a look at AggPas, which can easily accomplish what you ask for - with out 0-1% CPU load (tested previously on my system). Lazarus includes a copy of AggPas as standard.

Here are some examples to show you smoothness - and even warped text on a bezier curve.

http://crossgl.com/aggpas/aggpas-demo.htm

Take a look at the Trans_curve1.exe and Trans_curev2.exe example executables (if you have Windows).

AggPas as been tested on Linux, Windows, FreeBSD and OS/2. And on 32-bit and 64-bit where OSes support that.

Regards,
- Graeme -

El 10/11/15 a les 16:55, Graeme Geldenhuys ha escrit:

Impressive, but I looked at the source and it uses its own kind of application.
Anyway, I don't think that cpu is the limiting factor, the application loop is.
Let me explain: I modified the application so that, instead of a big background bitmap that needs to be redrawn every time the text moves, I have two, the big one and a smaller one just where the scrolling label is (I used BGRABitmap to split the previous one in two).

I then used a thread with a simple loop

   while not terminated do
   begin
     sleep(FOwner.FScrollRefresh);
     Synchronize(@SyncTimer);
   end;

where synctimer just updates the offset and invalidates the label so that it redraws itself.

On a virtualized windows xp I can use FScrollRefresh of 1 and it scrolls very fast and the application is responsive.
On a real hardware windows 7 (in theory much more powerful) or a virtualized one, not only the refresh cycle is much longer (I suppose the limiting factor is the rate of the CheckSynchronize calls from the main thread), but it cannot cope with the other messages (i.e., I update a clock with a timer, but it doesn't update, it doesn't react once I clicked on the button to confirm exit, etc.).
Before I thought it was cpu bound (since it had to repaint the whole screen), but now that it only repaints 10% it works exactly the same. The strange thing is, it seems to work fine (albeit not at the rate it works under xp) if I start it as wsNormal (the application should be wsFullScreen and BorderStyle bsNone).

Bye

Probably you are somewhere wrong, provide your code so we can check.

Regards,
Ara

Luca Olivetti wrote

Impressive, but I looked at the source and it uses its own kind of application.

Don't let the demos confuse you. The demos were implemented to be cross-platform in their own way, with its own widgets used by the demos. The idea comes from the original C++ AGG framework, and only meant for the demos.

You can use the AggPas API directly (most powerful) in Lazarus or fpGUI or Console applications. There is also a TAgg2D Canvas class which gives you a more Delphi-like Canvas API - a much smoother/easier introduction to AggPas. The TAgg2D canvas is available for LCL and fpGUI.

Regards,
- Graeme -

Aradeonas wrote

Probably you are somewhere wrong,

+1

Regards,
- Graeme -

I am actually working on a new project which will be used to create a beautiful text animations. I'm not sure when I'll have anything previewable done, but the basic idea is you layout curves with spline nodes, put text on the curve, set timeline values for text offset in x and y along the curve, set timeline values for curve node changes, and press render to create an mp4 of the animated text suitable for video title sequences. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151110/088cdc20/attachment.html>

El 10/11/15 a les 18:47, Graeme Geldenhuys ha escrit:

But in the end I have to render it on the LCL canvas (a simple TextRect), and I cannot do it faster than the LCL allows me. If I use a timer[**] I'm constrained by the timer resolution (around 15ms in windows with a minimum value of 10ms), if I use a thread+synchronize I'm constrained by how often the application loop calls CheckSynchronize (aside: if I move the mouse over the label, it goes faster, probably because the application is managing more windows messages and calls CheckSynchronize more often).
I also tried without Synchronize, but that's a no-no (apparently works until you hit a timing issue and the application crashes or gets stuck).

[*] there are also multimedia timers, but I don't know if/how I can use them, and they are windows specific anyway.

Bye

If you have a design and could share it,send it to me maybe I can make an example.

Regards,
Ara

El 10/11/15 a les 17:48, Aradeonas ha escrit:

Here is the component I adapted from the forum posting. Originally it used a timer instead of a thread and I have to clean it up once I decide for one option or the other.
Tomorrow I'll see if I can create a simple application that reproduces the problem using it.

Bye

Luca Olivetti wrote

But in the end I have to render it on the LCL canvas

Via a single BitBlt which should be more than fast enough for what you described. Unless LCL is seriously broken.

But as the AggPas demos shows, text animation (more advanced that what you described - movement of text on a constantly moving bezier curve) is easy and possible with excellent results. So AggPas will not be the bottleneck.

Regards,
- Graeme -

Luca Olivetti wrote

Here is the component I adapted from the forum posting.

I quickly created my own scrolling label test widget for fpGUI. Attached is the unit. I set the scrolling step to 2 pixels and scrolling speed at 20 milliseconds. It uses a fpGUI Timer (no threads). I didn't even use AggPas, just the standard Canvas.DrawText().

The result is a smooth horizontal scroll at a readable speed. CPU load was a constant 0.5% which is considered pretty much idle. Moving the mouse or the window makes no difference to the scrolling speed.

Feel free to port that to LCL and see how it fares.

Regards,
- Graeme -

El 10/11/15 a les 23:37, Graeme Geldenhuys ha escrit:

I don't know if it's broken, but, AFAIK, there are two ways to animate something

1) with a timer (constrained by the windows resolution)
2) with a thread+synchronize (only the main thread can access the gui, and the constraint here is the rate the application loop calls CheckSynchronize)

But what really puzzles me is the different behavior between xp and 7 (maybe it's aero, I could try disabling it). The fact that it's a font of size 100 with a bitmap below it doesn't help, but it should be possible.

But as the AggPas demos shows, text animation (more advanced that what you described - movement of text on a constantly moving bezier curve) is easy and possible with excellent results. So AggPas will not be the bottleneck.

See above, the problem lies somewhere else, a simple TextRect is enough for what I'm doing. I just used BGRABitmaps to split the background image so only the part under the scrolling label has to be redrawn (I probably could have done the same with TLazIntfImage), but it didn't help.

Bye

El 11/11/15 a les 01:21, Luca Olivetti ha escrit:

Well, I just found out that in a virtual machine (be it xp or 7) the timer resolution is 10ms, while in real hardware is 16ms (no matter if I use a timer or a thread+synchronize).
That at least explains the timing differences (but not the unresponsiveness of the full screen application under windows 7)

Bye

Using OpenGL etc. risks breaking the program for anybody accessing it over remote X (including SSH) or VNC etc. (either for routine use or remote support).

I believe there are ways that OpenGL can be mapped over a LAN, but in practice it would- at present at least- be safest to assume that these aren't reliable and at the very least provide a user option to make sure the program doesn't attempt to use it for anything that is basically cosmetic.

El 11/11/15 a les 09:28, Luca Olivetti ha escrit:

That at least explains the timing differences (but not the unresponsiveness of the full screen application under windows 7)

TextRect!

Try the attached project.
Under windows XP the TextRect takes an unmeasurable amount of time (using GetTickCount).
Under windows 7 it takes 160ms here when in full screen (1920 pixels wide) or 60-70ms when using the --debug option (320 pixels wide).

Bye

El 11/11/15 a les 10:16, Luca Olivetti ha escrit:

That was on virtual hardware, BTW. On real hardware instead of 160 it takes 40-60. It's still a lot of time compared to a virtualized windows xp.

Bye

Luca Olivetti wrote

Try the attached project.

LCL inconsistency strikes again.

   WindowState:=wsMaximized;

The above line of code has no affect under FreeBSD with LCL-GTK2. I see a small borderless window with a button on it.

Anyway, I tested your project under FreeBSD LCL-GTK2 and Windows 2000. Scrolling was smooth (with one exception) and CPU load was idle (< 1%). Under Win2000 the application was full-screen, under FreeBSD it wasn't.

Having the modal quit dialog open did not affect the scrolling speed. I also couldn't see any visible change in speed while moving the mouse.

The exception I mentioned was when I run the test project under Win2000 with the --debug option. There was visible flicker the whole time while the application was running.

Regards,
- Graeme -

El 11/11/15 a les 10:26, Luca Olivetti ha escrit:

More testing: I added a spinedit to change the size of the text. Under windows xp I can go until 124, then it starts becoming as slow as windows 7.
Under windows 7 the maximum value is 83, at 84 is slow. Any idea on what could be the cause?

Bye

Yep.

But scrolling text via VNC will not work decently, anyway.

-Michael

El 11/11/15 a les 10:28, Graeme Geldenhuys ha escrit:

Thank you for testing.
Yes, but that's not relevant. I put it there just to do the same the real app is doing. It also behaves differently with linux-gtk (it maximizes) and linux-qt (it doesn't).
:-(
Also, on linux-gtk2 I tried up to size 300 and more, while linux-qt starts becoming slow at 49.

Anyway, I tested your project under FreeBSD LCL-GTK2 and Windows 2000. Scrolling was smooth (with one exception) and CPU load was idle (< 1%). Under Win2000 the application was full-screen, under FreeBSD it wasn't.

OK, windows 2000 probably behaves like windows xp.

Having the modal quit dialog open did not affect the scrolling speed. I also couldn't see any visible change in speed while moving the mouse.

Yes, that's normal, I'm using a timer. The visible change in speed was when I was using a thread with synchronize.

The exception I mentioned was when I run the test project under Win2000 with the --debug option. There was visible flicker the whole time while the application was running.

Strangely (or not) enough, it depends on the theme. With XP I see the flickering if I use the classic theme, no flickering with the teletubbies one.

Bye