Here you are.

I attach an svn diff, with the RawImage_FromDevice implemented for CD_X11. A few details.

1) The image format I was getting back didn't fit any of the precanned RawImage.Description which you may get with Description.Init_BPP32..., and therefore the colors were not too well preserved. Getting all the proper values from X requires some work, to figure out how X things match Lazarus things.
I took a shortcut, and added a DescriptionFix, which just puts in the right parameters for my screen (by looking to what GTK gets back with the same call). They may be not the most appropriate for yours.

2) I've fixed the bug which caused the new timer crash. It was due to some extra changes I had made to experiment with a Timer in a different thread.

3) You'll find my experiments too, but they're disabled, and won't affect you, unless you want to give a try.

4) You may find a screenshot of the screenshot ( =) ) taken by my test program at:
http://www.copeca.it/colla/magnifier.png
showing the terminal window whith the profiling of an Expose event. To be discussed elsewhere. I'm afraid that roughly 200 ms per frame isn't a very good speed.

Enjoy,

Giuliano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Vmg.diff
Type: text/x-patch
Size: 25898 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120404/e82762d4/attachment-0001.bin>

Thanks, applied in rev 36558 =)

Some comments:

1> I think that we should add cthreads somewhere in LCL-CustomDrawn-X11 because otherwise sqlite projects crash with wierd problems =( Then threaded timer could become the default if that's what you want. But this does not exclude that we should always keep the possibility of having everything work without threading.

2> Please make a manual inspection of the diff before sending. Notice that apparently you had merging issues with my changes in the meantime so your diff had info to delete my changes

3> Please note how I managed to create a more clever cross-backend implementation for GetDeviceSize. You can't implement a new routine only for 1 backend. The idea case is like I did: It works in all backends ;) The second choice is having an additional routine called BackendRoutineName, then the common routine will run for the common case (for example DC=LazDC) and just calls BackendRoutine if we are a non-common case like DC=0. The third option is each backend having a different code.

Felipe Monteiro de Carvalho ha scritto:

I would consider Threaded Timer experimental, for now, just to evaluate if it does provide a real advantage, or not. If we can manage to do without, one thing less to worry about. If it proves really useful, then we must decide how to make it available with a minimum hassle for a plain normal user.

2> Please make a manual inspection of the diff before sending. Notice that apparently you had merging issues with my changes in the meantime so your diff had info to delete my changes

I tried to, but sometimes I fail to understand the svn logic. It raises a conflict just because there's a blank line before or after an ifdef. As you have much more experience than me in sending patches, what do you suggest, in order to avoid troubles?

I just picked up the code from GTK. Then I knew that you would revise it, taking into account other backends... ;-)

Giuliano Colla wrote

I tried to, but sometimes I fail to understand the svn logic. It raises a conflict just because there's a blank line before or after an ifdef. As you have much more experience than me in sending patches, what do you suggest, in order to avoid troubles?

Some files had only my changes, so it should never had given you any trouble, the merge should be automatic. It is simple, always before starting a work and in your case before making the final patch too, do:

cd lazarus
svn up

To make the patch:

svn diff > mypatch.diff

To visually inspect it:

gedit mypatch.diff

If it shows any errors, just post them to me. Errors are rather rare. Most merging should be automatic

Strange, drawing the screenshot into the control fails using the magnifier

And if you are fealing particularly motivated for X11 stuff, another missing feature for the magnifier is TTrayIcon =) I guess we could copy my old gtk code which used X11 directly.

Ok, now I fixed the screenshot code =) rev 36559

Issues:

1> The ScreenDC is not zero. It is WND=0 which results in the DC returned by GetDC(0) which will return CDWidgetset.ScreenDC. Each interface should created a buffered TLazCanvas for ScreenDC operations. I added some generic code in case the buffered ScreenDC is not created and a new nice routine IsScreenDC(DC)

2> It was thinking that the DC has always size (100, 100), I fixed that.

The test case for screenshot taking is lazarus/examples/canvas_test which has a screenshot test.

Nasty bug I just found: It seams that resizing forms with Align alNone crash at least in X11 =(

Felipe Monteiro de Carvalho wrote

And if you are fealing particularly motivated for X11 stuff, another missing feature for the magnifier is TTrayIcon =) I guess we could copy my old gtk code which used X11 directly.

Ok, I started it, but nothing working yet ...

Strange, the magnifier doesn't move in X11, it gets freezed in the first position, but it moves in Mac. The move event seams fine, however. Maybe a problem with invalidation?

Il 04/04/2012 21:43, Felipe Monteiro de Carvalho ha scritto:

Strange, the magnifier doesn't move in X11, it gets freezed in the first position, but it moves in Mac. The move event seams fine, however. Maybe a problem with invalidation?

Where can I pick up a copy of the source to give a look?

Giuliano

Giuliano Colla wrote

Where can I pick up a copy of the source to give a look?

See this page: http://sourceforge.net/projects/magnifier/develop

Il 05/04/2012 07:33, Felipe Monteiro de Carvalho ha scritto:

A very quick try. Results on my platform:

GTK: works fine. Not so smooth as desirable, but quite acceptable.

Qt: very slow. Usable but annoying. Crashes on exit.

CD: It doesn't move. Stuck at the upper left corner of the screen, as if mouse position were always [0,0]. Either it doesn't receive mouse position, or it gets a wrong window position. Or both. Now I have a lot of work to do, but ASAP I'll investigate further. Most likely, it will point to what is still unimplemented in CD X11.

BTW. I've implemented a first quick and dirty SmartPaint option, to avoid repainting the window if nothing has changed. It looks promising, but again I have no time to send a clean diff.

Giuliano Colla wrote

GTK: works fine. Not so smooth as desirable, but quite acceptable.

That's what I distribute for Linux at the moment.

Good idea! Indeed GetCursorPos is not implemented for X11!

Implemented in rev 36571 =)

Now we can see the motion graphic going.

BTW. I've implemented a first quick and dirty SmartPaint option, to avoid repainting the window if nothing has changed. It looks promising, but again I have no time to send a clean diff.

I already implemented this once purely on the frontend code, but it was not effective and had bugs, so I dropped it. Indeed in the backend side this could be done in a much more efficient way, it could send the buffered native image.

But again: Make absolute sure that you are verifying if the window did not change it's size. If it did, you need to invalidate the entire form and rebuild the native image.

But this optimization is only useful in platforms which keep sending us unnecessary repaint messages: X11 and Windows. Android and Cocoa only request a repaint if really indispensable. Cocoa/Android buffers our window and will not request a new image if you just partially cover a window. This optimization will diminish CPU usage but the user will probably not notice any difference in the VMG. Making the painting itself faster is what is needed for motion graphics.

Felipe Monteiro de Carvalho ha scritto:

Very good, as soon as I'm in a suitable platform, I'll try and evaluate. Each application is useful to show different areas of implementation/optimization.

There's still some issue in resizing. During resize, sometimes apparently it takes momentarily a wrong scanline, and the image comes out distorted.
Without SmartPaint you see this effect for a moment, but then the image is repainted, even if the resize is finished, and so it's just a blink. With SmartPaint if you stop resizing exactly at that moment the image is not repainted, and you see a distorted window. But this is more a issue of EvPaint than that of SmartPaint. Maybe it lacks the appropriate locks and it updates an image while it's being written. Must investigate further.

But this optimization is only useful in platforms which keep sending us unnecessary repaint messages: X11 and Windows.

Yes it's Backend specific. But Windows and X11 sum up 95% of users!