Hello,

In the last days I was working in something like an animation library that allows me to perform flashing messages, collapsable panels, and other simple animation effects.

The pre-requisites are no threading involved, it must be able to animate anything (abstraction) and life cycle must be handled by the engine.

Finally I end with and alpha version which I wish to share with the community to get a bit of feedback before include it in Lazarus CCR or maybe in LCL itself.

The current code has two "libraries", the "uanimationbasic" which handles the objects life cycle and coordinate operations and a derived "uanimationcontrol" with a series of animations to be used in form controls.

As demos uses images the size of the package are quite big to be included in this email so you can download it from:

http://dyn.consultem.org/jfanimlib.zip (268 Kb).

Attached screenshot of controls sample.

It has been tested with Lazarus 1.6 and fpc 3.0.0 in Windows, but Linux should work also.

I get an error on uanimationcontrol.pas, line 621:

     NRect.Width:=CalculateLinearPosition(FInitialRect.Width,FFinalRect.Width,GetElapsedMilliseconds,FDuration);
     NRect.Height:=CalculateLinearPosition(FInitialRect.Height,FFinalRect.Height,GetElapsedMilliseconds,FDuration);

fpc 3.0.0, linux 64 bit.

Michael.

José Mejuto wrote

It has been tested with Lazarus 1.6 and fpc 3.0.0 in Windows, but Linux should work also.

I tried to compile the "Animated Controls Sample" project and got the following errors under 64bit FreeBSD using FPC 3.0.1

==============================
Hint: Start of reading config file /home/graemeg/.fpc.cfg Hint: End of reading config file /home/graemeg/.fpc.cfg Verbose: Free Pascal Compiler version 3.0.1 [2016/05/09] for x86_64 Verbose: Copyright (c) 1993-2015 by Florian Klaempfl and others Verbose: Target OS: FreeBSD for x86-64
Verbose: Compiling controlsample.lpr
Verbose: Compiling frmcontrolsample.pas
Verbose: Compiling /tmp/test/src/uanimationbasic.pas Verbose: Compiling /tmp/test/src/uanimationtypes.pas uanimationbasic.pas(619,3) Note: Local variable "lUseHighPrecision" not used Verbose: Compiling /tmp/test/src/uanimationcontrol.pas uanimationcontrol.pas(619,11) Error: identifier idents no member "Width" uanimationcontrol.pas(620,11) Error: identifier idents no member "Height" uanimationcontrol.pas(672,0) Verbose: There were 2 errors compiling module, stopping
Verbose: Compilation aborted

==============================

I then tried with FPC 3.0.0 and got the exact same error.

According to FPC's types.pp unit, the TRect doesn't have a Width and Height property.

============================================
{$ifdef Windows}
  TRect = Windows.TRect;
{$else}
  TRect =
{$ifndef FPC_REQUIRES_PROPER_ALIGNMENT}
  packed
{$endif FPC_REQUIRES_PROPER_ALIGNMENT}
  record
    case Integer of
      0: (Left,Top,Right,Bottom : Longint);
      1: (TopLeft,BottomRight : TPoint);
    end;
{$endif Windows}
  PRect = ^TRect;
============================================

Regards,
Graeme

Graeme Geldenhuys wrote

According to FPC's types.pp unit, the TRect doesn't have a Width and Height property.

FPC 3.0.2 should have it (through a class helper).

Ondrej

Hello,

Correct, swapped compilers :-( a few days ago :-(. Just change declaration of NRect from TRect to TAnimationRect and a bit below the:

DoMoveControlAsRect(NRect);

to:

DoMoveControlAsRect(NRect.GetAsRect);

José Mejuto wrote

Correct, swapped compilers :-( a few days ago :-(. Just change declaration of NRect from TRect to TAnimationRect and a bit below the:

Before I read your reply I simply adjusted the code as follows (which worked):

    NRect.Right := NRect.Left +
CalculateLinearPosition(FInitialRect.Width,FFinalRect.Width,GetElapsedMilliseconds,FDuration);
    NRect.Bottom := NRect.Top +
CalculateLinearPosition(FInitialRect.Height,FFinalRect.Height,GetElapsedMilliseconds,FDuration);

The sample program runs and all animations (except "Alpha bend this form" functionality) works. Two points though:

1) The FPS counter in the form title doesn't seem to function. Instead of a FPS counter it seems to simply be a counter that constantly grows.

2) I have a 4 core system with hyper threading (ie: 4 cores and 4 virtual cores). Your sample application maxed out all 8 cores at 100% CPU load. Not really acceptable behaviour for a desktop application I would think. ;-)

Regards,
Graeme

Graeme Geldenhuys wrote

The sample program runs and all animations (except "Alpha bend this form" functionality) works. Two points though:

Hello,

I don't know of the alpha blend form is possible in Linux and using you windows manager.

1) The FPS counter in the form title doesn't seem to function. Instead of a FPS counter it seems to simply be a counter that constantly grows.

Hmmm... I must review it, in Windows works but maybe in Linux (not using getperformancecounter) it simply goes crazy.

2) I have a 4 core system with hyper threading (ie: 4 cores and 4 virtual cores). Your sample application maxed out all 8 cores at 100% CPU load. Not really acceptable behaviour for a desktop application I would think. ;-)

The library animate controls properties, like position and color at the rate set by the "tmrAnimationCadence" timer. Maybe Linux LCL takes ages to update control positions or the backend widgetset. The CPU use for the library operations are almost 0% but repaint the form is CPU intensive specially in Linux, based in your observations. There is no reason that more than one core is used (no threading) so the widgetset or LCL interface is pushing it to its limits.

You can try to remove the "Self.Refresh" in the tmrAnimationCadence event and also raise the tmrAnimationCadence.Interval to 30 (in the published code its value is 1, but it should be 15, but in Windows difference between 15 and 1 is zero, in Linux you can set timers with 1 ms. precision which is terrible overkill).

I put it on 30, but as with Graeme, the CPU goes to well over 100% (2 cores are involved in the process, or so it seems)

Michael.

[...] Finally I end with and alpha version which I wish to share with the community to get a bit of feedback before include it in Lazarus CCR or maybe in LCL itself.

Instead of Repaint it should use Invalidate.

And when changing multiple LCL properties, you should enclose it in DisableAutoSizing/EnableAutoSizing.

For example:
  DisableAlign;
  AnimationQueue.PaintAll;
  EnableAlign;

Mattias

Hello,

I'll investigate a bit why in Windows it takes low CPU usage but in Linux it overload CPU, maybe too much FPS or the Linux LCL behavior should be handled in a bit different way.

Thank you for your tests.

Mattias Gaertner wrote

Instead of Repaint it should use Invalidate.

Hello,

Invalidate queues a paint but repaint calls an inmediate repaint do not?

In other words, in Windows world Invalidate uses PostMessage and Repaint uses SendMessage, or am I wrong ?

Yes, I forgot to disable the autoaling, this for sure will reduce CPU when many controls are being moved at a time, thank you.

This confirms that the lib is not ready to be used :-)

Yes.
The widgetset can combine multiple invalidates to one paint, avoiding congestion.

Mattias

Graeme Geldenhuys wrote

2) I have a 4 core system with hyper threading (ie: 4 cores and 4 virtual cores). Your sample application maxed out all 8 cores at 100% CPU load. Not really acceptable behaviour for a desktop application I would think. ;-)

Hello,

Performed some tests today using VirtualBox, Ubuntu 14.04.02 and Centos 6.7, both 32 bits using Windows 7 as host with a CPU i7 (3 cores for virtual machines and 2 gigabytes of RAM).

Ubuntu
------
- Default configuration from Virtualbox the animation takes CPU near 100% in all cores with compiz using 95% of CPU wichever frames per second I use. The Windows manager is damn slow, just open Lazarus and move components around a form is sloooowwww.
- Activated 3D acceleration and now animation is good at ~60 frames per second with an average CPU of 10-15%. Also removed the FPS in caption as only that update takes 50% CPU sometimes, something is wrong in compiz with windows captions.
- Host Windows 7 machine with Ubutu animation running uses around 12-16% CPU for the VirtualBox.

Centos
------
- Gnome with default VirtualBox configuration (no 3D acceleration) works fine at ~60 frames per second once Form.Caption update is removed as it consumes CPU (only form.caption update consumes 60% CPU sometimes).

Conclusions:
Ubuntu compiz needs 3D acceleration to be usable and has window caption bugs, the update of caption produces artifacts in form controls like missing draws, blank zones, ghost lines, ... Of course this could have some relation with LCL updating the caption as its CPU consume is insane. In the other hand, form.caption update in GNome works quite well, not as smooth as Ubuntu but quite similar to Windows7.

In linux Form.invalidate/repaint seems to work different than in Windows, as in Linux it seems to not remove queued paints, so moving a control and just issue a form.invalidate the system paints the control and children controls and then form.invalidate paints all of them again. In windows AFAIK when form.invalidate is called all paints in the queue are removed (related to that window) without being processed and then form.invalidate is performed.

I wish to know if somebody think this is useful, to expand it, or just don't take more time developing it and keep it to my projects.

Thank you.

José Mejuto wrote

I wish to know if somebody think this is useful, to expand it, or just don't take more time developing it and keep it to my projects.

By all means please do continue if you have the time and energy. :) We were simply testing your work - it's always good to test on various platforms. Just so you know, I'm using 64-bit FreeBSD. I don't run a desktop environment, but instead a old-school style Window Manager (called JWM - Joe's Window Manager). JWM is extremely light - only uses 8MB of RAM so never interferes with application performance tests.

Regards,
Graeme

Do you use JWM just for testing, or JWM all the time for all work?

Lars wrote

Do you use JWM just for testing, or JWM all the time for all work?

I've been using JWM non-stop for the last 4 years! I'll never return to a bloated "desktop environment" again.

Things I like about it:
* I only activate the global shortcuts I need like Alt+F2, Alt-Tab. Nothing else, so it never conflicts with any application shortcuts.
* Menus are a breeze to edit. I even used a 3rd party tool that generated JWM include files from Gnome/KDE menus (but don't do that any more).
* My desktop/application menu only contains what I need and use, and items are grouped to what makes more sense to me.
* Clicking anywhere on the desktop window brings up the application menu.
* Virtual desktops are built-in, as well as dragging apps from one virtual desktop to another
* A Win95 like "taskbar" is built-in (optional). The same for the trayicon areas.
* A simple theme with rectangular windows (very configurable if you are into that kind of stuff, and you can configure rounded corner windows too).
* The ability to restart JWM without having to shut down X11 or any of your applications.eg: to refresh the application menus or other config settings after being edited.
* It's fast and very light with RAM usage.
* Works perfectly with multiple monitors (I have 3), and I configured the taskbar to the center monitor only.

I can send you my config file if you want to see my layout.

Regards,
Graeme

Hi Graeme,

<snip>

I've been using JWM non-stop for the last 4 years! I'll never return to a bloated "desktop environment" again.

Sounds interesting to me... I always tend to have multiple desktop environments/window managers installed. i have two questions:
1. Do you have any idea how it compares to Fluxbox? It sounds pretty similar to me? Maybe even lower on resources?

<snip>

* Menus are a breeze to edit. I even used a 3rd party tool that generated JWM include files from Gnome/KDE menus (but don't do that any more).

What tool did you use for this? I tend to edit my KDE menus with Kmenuedit and really do not want to do it all by hand again in a text file (or is there another way to do this)?

I use Debian (with extra repositories) and find that almost always some of the programs I have installed with aptitude do not show up on the menu.

Regards,
Chavoux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170308/f5cf3380/attachment.html>

I replied in a private email.

Regards,
Graeme

When I finally get around to installing freebsd, if I can remember. What do you do when you need to run a Windows lazarus program?

My biggest gripe with bsd/linux is that I'd constantly have to switch back to Windows/MacOSX to do testing as those are the major platforms to sell apps on. So if I switch to BSD I'd likely end up just having to run Windows inside bsd in an emulator anyway. Catch22. You ever run lazarus inside a windows emulator inside bsd? that's likely what I'd end up doing, or compiling for windows inside bsd then testing the app in a windows emulator. I'm not sure what the emulators/virtualbox's are available for bsd.

Lars wrote

When I finally get around to installing freebsd, if I can remember.

JWM runs on any X11 system... Linux, FreeBSD, Solaris etc. But yes, FreeBSD is a brilliant choice. I much prefer it over Linux too.

What do you do when you need to run a Windows lazarus program?

WINE, just like under Linux. Or you can run VirtualBox with a Windows guest. This is how I test on various Windows and Linux platforms. I don't know how any developer can not run some or other VM in this day and age.

If you speak to Delphi developers, most of them run Delphi in a Windows VM, using a Apple computer.

VM's also give you a lot of piece-of-mind. If your real hardware fails, move the VM to any other system and continue where you left off - hardly any down time. I regularly make backup copies or take snapshots of my VM's too. Snapshots are very handy for experimentation.

Speaking of emulators, FreeBSD also includes a Linux Emulator (an actual CentOS 6.6 install I believe), so you can run FreeBSD, Windows and Linux applications without firing up a VM. Pretty neat!

I'm not sure what the emulators/virtualbox's are available for bsd.

VirtualBox, Xen, Bhyve, FreeBSD Jail, QEMU etc... VMWare doesn't support FreeBSD. I've been using VirtualBox for about 7 years now (headless and GUI) and it works brilliantly! Bhyve is actually part of the base FreeBSD system now, so it's built into the operating system.

As for developing cross-platform applications, even if Windows is your largest seller, if LCL did it's job correctly, you should be able to develop under any platform, then simply cross-compile (or compile natively in a VM) and things should work everywhere the same. In the real world LCL is unfortunately not there yet, but close.

Pure fpGUI Toolkit applications have had that ability for 7+ years now. With fpGUI I only develop personal and commercial applications under FreeBSD, then at release time I compile binaries for other platforms and test (obviously). Since 7+ years I've never had incompatibilities across platforms - my applications work everywhere identical. I guess this is just one of the many benefits of 100% custom written toolkits.

Regards,
Graeme

Except for the fact that VM's suffer from corrupt hard drive file problem. All your files are stored in a file, which is extremely dangerous compared to having files stored as separate files. If one little bit is f**ked in that hard drive disk image file, all your work is lost, unless you can magically hack the file yourself into good shape which is equivalent of trying to make a square become a circle :-)

This is the only real thing stopping me from using vm's more often is if I save any work to the VM disk image, it scares me that the disk image could become corrupt. You could back it up daily to GIT I suppose, but that would be a massive file to upload to git... way too big... Maybe on a local git server in your home with a 1000 speed network card instead of 10/100

OpenBSD also allowed you to run Linux exe's (elfs) AFAIR in some kind of linux jail on the system.

Too bad OpenBSD developers are a bunch of criminal twats who stalk and taunt people, along with restricting speech on their mailing lists. To keep this post on topic, I did want Lazarus to run on OpenBSD , not sure if any progress has been made there. I know some efforts were made to get fpc working. But now I could care less.

Lars wrote

Except for the fact that VM's suffer from corrupt hard drive file problem.

Not a problem if you run a ZFS RAID-Z1 (which I do), or RAID-Z2 or RAID-Z3 environment. Read a bit (or look on YouTube) about ZFS - it's f**ken brilliant! A file-system redeveloped from the ground up. I will not use any other file system ever again.

I use server grade hard drives for the ZFS data pool and my setup allows one hard drive to fail without loosing data. Ideally you would want ZFS RAID-Z2 (allowing two drives to fail without loosing data), but I simply didn't have the space in my casing. So every few years I swap out one drive at a time for a new one.

In summary, ZFS is a copy-on-write file-system, so existing data is never overwritten on a write. All drives added to the pool becomes part of the collective hard drive space (think of it like RAM modules being plugged into a motherboard). "Partitions" can be created and destroyed at will, and can grow or shrink with the data. Sensitive data can be told to have multiple copies stored - scattered over the pool. ZFS does crc checks before and after read/writes to verify the data, so no faulty cable, controller or hard drive will silently corrupt your data. And contrary to what many may think (because of the latter statement), the performance of ZFS is fantastic.

ZFS (same version as FreeBSD) is now available for Linux too, thanks to the OpenZFS community - development of ZFS is now a collaborated task. To install ZFS in Linux is very simple and quick, and unlike a couple years ago, ZFS doesn't run under FUSE on Linux any more, it's a truly native file system, just like EXT4, JFS etc.

If you have 3 or more USB memory sticks, use them to play around with ZFS to get a feel for it. It's a nice and easy way to simulate hard drive failures etc. You can use virtual VM hard drives too of course.

This is the only real thing stopping me from using vm's more often is if I save any work to the VM disk image, it scares me that the disk image could become corrupt.

Like I said, I also make the occasional backup of my VM virtual hard drives by exporting it to a ova file.

As for any code written inside a VM. I normal use-case is to enable a shared folder in the VM, so my code is not actually stored on the VM's hard drive, but directly on my ZFS data pool.

Saying that, I do have customer or project specific VM's where the code is stored in the VM. In such cases, at the end of the day, I simply push my code changes to my remote Git repository (outside the VM and accessed via SSH), so I have a second backup copy of the code.

I've been developing like this for over 7 years and haven't lost a single line of code.

that would be a massive file to upload to git... way too big... Maybe on a local git server in your home with a 1000 speed network card instead of 10/100

Don't do that. Simply push the code changes, not the VM hard disk.

Now I'm curious... How do other developers work? What environments do you guys use? Do you develop on VM's or real hardware? Any specific host OS of choice, VirtualBox, VMWare or something else. Where do you store your source code - in the VM, outside or both?

Regards,
Graeme

Hello,

It is as dangerous as all your files are in a harddisk, if the harddisk crashes ( physically ) you lost all your files.

It's almost impossible to corrupt a virtualbox disk image as its inner working is too much simple. Even if a corruption happens its very easy to convert to a dd raw image and mount it in your favorite OS. The only corruption that will certainly ruin your VM disk is a page allocation corruption, which is mostly as you overwrite the NTFs MFT and partition table and/or your ext3/4 iNode table.

I'm using my VM's as real computers, so backups are usual but from inside the VM (SVN for sources and backups for other files) not a virtual disk image copy (VM must be stopped).