bgragui and msegui.

[fredvs]

Hello everybody.

I hope all ok for you in that strange period.

I did some more test with BGRABitmap and MSEgui.

All ok but there is problem with the BGRABitmap bridge and all MSE widgets that use fpimage (error while trying to load png or other bitmap files for example).

Till now I did not find the reason why the bridge caused problems because in MSE source all fpimage* files in /msegui/compatibility/ are renamed into _msefpimage* and in each uses section of MSEwidgets use now _msefpimage*.

Anyway, it is about only few widgets, like Tmseimage, Tmseimagelist and disabling the bridge makes it work. Of course the best would be to find why Tmseimage has problem with the bridge.

But maybe it could be good too to have his own Tbgraimage and a Tbgraimagelist so no need to use the Tmseimage.

Have a perfect week end.

Fre;D

[fredvs]

Hello.

The problem with Tmseimage and the bridge the bridge is solved! The fixes are in last commit of MSEgui.

[circular17]

Cool

[circular17]

What was it?

[fredvs]

Hello Circular.

What was it?

In lib/common/image/msegraphicstream.pas, the dest persistent-const has to be changed with bridge define:

function readfpgraphic(const source: tstream; const readerclass: fpreaderclassty;
            const dest: {$ifdef class_bridge}classes.{$endif}tpersistent): boolean;  // this changed

And in mclasses, tpersistentbridge.Assign: the 3 first lines have to be commented:

procedure tpersistentbridge.Assign(Source: TClassesPersistent);
begin
 // if Source is tpersistentbridge then
 //   Assign(tpersistentbridge(Source))
 // else
  inherited Assign(Source);    
end;

I did test to import images in TMSEimage and TMSEimagelist and it works now with the bridge.

Of course I did test for BGRAbitmap and it works too:

procedure tmainfo.onpaint(const sender: twidget; const acanvas: tcanvas);
var
  bmp: tbgrabitmap;
begin
 bmp := TBGRABitmap.Create('msegui.png');
  bmp.fillellipseantialias(
  sender.bounds_cx / 2, sender.bounds_cy / 1.5 ,
   sender.bounds_cx / 2, sender.bounds_cy / 4,
   cssred
  )
  bmp.draw(acanvas, 0, 0, false);
  bmp.free;
end;

Here result of a demo that share TMSEimage, BGRABitmap image and bgragui widgets:

[circular17]

Lovely

I see why you would have to add {$ifdef class_bridge}classes.{$endif} but I think the second change is not great because it removes the use of AssignTo(tpersistentbridge).

[fredvs]

but I think the second change is not great because it removes the use of AssignTo(tpersistentbridge).

Yes, I know, same feeling for me but otherwise importing a image in a Tmseimage fails.

Here result without the fix:

Just before to click OK:

And after OK:

May I ask you what kind of problem could generate the fix?

I did not find any problems at the moment.

Thanks to take care of mse.

Fre;D

[circular17]

Hmm it may not really matter.

Maybe we can remove altogether Assign(tpersistentbridge) and AssignTo(tpersistentbridge). Anyway when assigning one checks the actual type of the object.

[fredvs]

Ha ok, cool.

Huh, you are welcome for a Pull-Request (or to tell me exactly what to do).

By the way, I did finish the first shot of the "Chords Randomizer" of StrumPract for helping jamming. Only minor and Major chords are working, 7th and 9th will come.

There are binary releases here: https://github.com/fredvs/strumpract/releases

And I am very happy that BGRABitmap is working now with Tmesimage because I will attack the "Image Dancer" feature.

With a DSP, catch live the parameters of the sound, like volume, frequencies, ... and use it as parameters for BGRABitmap features to transform a image (color, effect, etc...).

And of course your ideas are more than welcome.

Fre;D

[lainz]

Cool. I want to see the image dancer.

[circular17]

Music! Music!

For me it is not convenient at the moment to do the change to the class bridge. Though it is simple I guess:

• remove the functions Assign(tpersistentbridge) and AssignTo(tpersistentbridge)
• remove the overload keyword for Assign(TClassesPersistent) and AssignTo(TClassesPersistent)

And see if it still compiles.

[fredvs]

Hello.

Doing it does not compile with those errors:

mclasses.pas(325,15) Error: (3058) There is no method in an ancestor class to be overridden: "Assign(tpersistentbridge);

line concerned is from

 TCollection = class(TPersistent)
...
 procedure Assign(Source: TPersistent); override; 

[fredvs]

Cool. I want to see the image dancer.

I will begin it next week...

[fredvs]

Cool. I want to see the image dancer.

Huh, I have to confess that I am a totally beginner with BGRABitmap.

Do you have some gallery or demos that show some transformations done with BGRABitmap? Transformation of image but also design or ambiance or texture done with BGRABitmap?

Thanks.

[lainz]

There is this repository https://github.com/bgrabitmap/demo

And this one https://github.com/bgrabitmap/bgracontest

As well the examples folder of BGRABitmap

[fredvs]

Gracias, es buena comida!

OK, see you in one semana for first result.

Fre;D

[fredvs]

Hmm it may not really matter.

OK, I will keep the last commit unchanged. Working with the bridge for imported bitmap images seems ok for BGRABitmap and TMSEimage.

I will deeply explore the BGRABitmap features (with the Image Dancer) next week, maybe something will appear (but I am nearly sure that all will be ok).

[fredvs]

Hello.

Here picture of Fractal Tree and Super Formula demo with MSEgui:

Here the source: fractal_tree_mse.zip

Here the source: superformula_mse.zip

There are some demos of Dancing Image.

It uses StrumPract with BGRABitmap for the animations.

Here video of Dancing Fractal tree and Super Formula:

image_dancer_fractaltree.mp4.zip

image_dancer_superformula.mp4.zip

The source is in https://github.com/fredvs/strumpract/

Fre;D

[fredvs]

Hello.

For infos, all works OK with BGRABitmap animations with -O2 optimization using fpc 3.2.0 on Linux 64 bit. This also using hours long.

But with -O3 optimization using fpc 3.2.0 on Linux 64 bit, after 3 songs the application freeze and crash.

[lainz]

Looking really good.

Maybe you can try -02 and turning on the other optimizations one by one to see wich one fails. (Well 3 songs is like more than 10 minutes, so it will take a lot to debug this way...)

Maybe an unfreed memory block?

[fredvs]

Maybe you can try -02 and turning on the other optimizations one by one to see wich one fails.

OK, tested, here result:

No optimization: OK even after thousand mixes. -O1 : OK even after thousand mixes. -O2 : OK even after thousand mixes. -O3 : Crash after 3 mixes -O4 : Crash after 3 mixes

(Well 3 songs is > like more than 10 minutes, so it will take a lot to debug this way...)

Huh, it is not 10 minutes but 3 direct mixes ( + - 2 seconds each). The merciless test is to mix songs from a list playing each a few seconds only.

Maybe an unfreed memory block?

Maybe but there is no memory leak and I really dont see where it could be. By the way, there is the same problem with fpGUI for optimization > O2. It was already signaled years ago in fpc bug report but seems to not be fixed yet.

Anyway it works perfectly with -O2. In full screen the animation is slower, but I fear there is nothing to solve this (or maybe you have a idea?).

[lainz]

Well with BGRAVirtualScreen you can redraw a part of the image instead of the entire image, but in this case I think is not possible to use that optimization, since is not easy to calculate (at lest I don't think how) the size of the superformula or the tree, an clear only that part and redraw...

Fullscreen anything CPU will work slowly, but in the other hand how you can draw that with OpenGL, the generation of the image is also taking time, and the conversion to texture? (I don't know really, I'm guessing)...

[fredvs]

Well with BGRAVirtualScreen

Do you think it would be possible to make BGRAVirtualScreen MSE compatible? I did try but there is too much LCL dependencies.

Fullscreen anything CPU will work slowly, but in the other hand how you can draw that with OpenGL, the generation of the image is also taking time, and the conversion to texture? (I don't know really, I'm guessing)...

I did not jump into OpenGL yet maybe one day... I did test the window Dancing Fractal tree and Super formula on a big TV via HDMI of my ThinkPad. Well, very good, a few slow but very good result.

What is fast is to change only the colors. Does it exist in BGRABitmap methods to change the palette of color,brigtness, gamma of a all canvas or image?

[lainz]

Better ask @circular17 he made bgravirtualscreen . And about the color stuff try looking at lazpaint sources there are a lot of filters and adjustments available but I personally never used them.

[fredvs]

Hello.

Here result using optimizations on Windows too, note that the problems occurs only on Unix, on Windows all is ok.

Windows: -No optimization: OK even after thousand mixes. -O1 : OK even after thousand mixes. -O2 : OK even after thousand mixes. -O3 : OK even after thousand mixes. -O4 : OK even after thousand mixes.

Linux: -No optimization: OK even after thousand mixes. -O1 : OK even after thousand mixes. -O2 : OK even after thousand mixes. -O3 : Crash after 3 mixes -O4 : Crash after 3 mixes

PS: It is not really important, this post it is just a reminder.

[fredvs]

It is not because of BGRABitmap, nor uos, nor MSE, it is something to do with Xorg and -O3, -O4 optimization. Very difficult to debug because the debugger does not help. In fpGUI mailing list we did try to find solution for the same Xorg problem with -O3, -O4 but without luck.

Do you know what advantage has -O3, -O4 optimization? Does it influence the speed of rendering?

[fredvs]

@lainz :+1:

Maybe an unfreed memory block?

Yep, you get something, using cmem for memory manager:

uses
cmem, ...

Result on Linux: -No optimization: OK even after thousand mixes. -O1 : OK even after thousand mixes. -O2 : OK even after thousand mixes. -O3 : OK even after thousand mixes. -O4 : OK even after thousand mixes.

[fredvs]

OK, last thing about optimization.

Huh, cmem did not solve all. With -O3 and -O4, the application does not crash but after 3 mixes, the animation stops, you must move the mouse, it works for some time then anim stop again, moving mouse restart it,...

So to resume, all is working perfectly with -01 and -O2 but with -O3 and -O4, even with cmem, there are problems, it is like some threads are paused.

[lainz]

At least it works =)

[fredvs]

Yes and very well.

Do you know if -O3 and -O4 have some influence with image rendering, it dont seem faster (before to crash)?

[fredvs]

https://github.com/mse-org/mseide-msegui/discussions/60