Lazarus

Programming => Graphics => Graphics and Multimedia => BGRABitmap and LazPaint => Topic started by: hedgehog on May 12, 2025, 10:34:43 am

Title: TBCFluentProgressRing bug
Post by: hedgehog on May 12, 2025, 10:34:43 am
Hi all and Lainz!

I found a terrible bug in my code that was causing choppy animation.

1. Comment out a few lines for the TBCFluentProgressRing.TimerEvent function (line 215)

Code: Pascal  [Select][+][-]
  1. procedure TBCFluentProgressRing.TimerEvent(Sender: TObject);
  2. //var  <--- comment this
  3. //  TickCount: QWord;  <--- comment this
  4. begin
  5. //  TickCount:= GetTickCount64;  <--- comment this
  6. //  FAnimationTime:= (TickCount - FStartTickCount) mod FPeriod;  <--- comment this
  7.   DiscardBitmap;
  8. end;

2. Add one line of code to the TBCFluentProgressRing.RedrawBitmapContent function.

Code: Pascal  [Select][+][-]
  1.   if FIndeterminate and FTimer.Enabled then // line 199
  2.   begin
  3.     FAnimationTime:= (GetTickCount64 - FStartTickCount) mod FPeriod; // <--- add this
  4.     a:= 3*FAnimationTime*pi2/FPeriod - pi; // line 201
  5.     da:= 2*abs(1 - 2*FAnimationTime/FPeriod);
  6.     if da<0.01 then da:=0.01; // <--- change this line
  7.     DoDrawArc(a-da, a+da, FLineColor);
  8.   end
Title: Re: TBCFluentProgressRing bug
Post by: lainz on May 12, 2025, 08:22:51 pm
Hi, do you have access to bgracontrols git? If yes please fix it. If not tell me and I will fix it.
Title: Re: TBCFluentProgressRing bug
Post by: hedgehog on May 13, 2025, 07:15:09 am
Quote from: lainz on May 12, 2025, 08:22:51 pm
Hi, do you have access to bgracontrols git? If yes please fix it. If not tell me and I will fix it.

Oh yes, I ask you to do this work.
(I changed the first message)
Title: Re: TBCFluentProgressRing bug
Post by: circular on May 13, 2025, 10:40:30 am
Hi hedgehog,

I sense that lainz might be inviting you to join the project. Open source projects are public projects and so active contributors are welcome, especially when you’re already identifying and resolving issues like this one. How do you feel about contributing more directly in the future?

Note: I've applied the change (https://github.com/bgrabitmap/bgracontrols/commit/9dfb8bfc348010eea6417e9e4db5f8b44f8917c8) on dev branch.

Regards
Title: Re: TBCFluentProgressRing bug
Post by: hedgehog on May 13, 2025, 12:00:55 pm
Hi,  Circular

Quote from: circular on May 13, 2025, 10:40:30 am
How do you feel about contributing more directly in the future?
Oh, Lainz already invited me (a year ago, I think).
The problem is that I don't understand the concept and basic principles of GitHub.
And some force doesn't let me study it and use it (maybe I'm too lazy?)
It would be great if Lazarus IDE had a "Send to GitHub" button. Or does it already exist and I don't know about it?

As for me, I really like creating graphic elements (controls).
I apologize in advance for what I'm about to write:

1. Standard controls are outdated. They look terrible. Like in 1995.
2. BGRA allows you to make very beautiful controls.
3. BGRAControls is now a set of different controls without observing a common style.
4. It seems to me that an initiative is needed to create a new set of visual controls in a single style.

Regards
Title: Re: TBCFluentProgressRing bug
Post by: cdbc on May 13, 2025, 12:51:08 pm
Hi
Quote
4. It seems to me that an initiative is needed to create a new set of visual controls in a single style.
+1
I sencond that  ...IF you/we/they can accomplish that with a SMALL (memory) footprint...
I personally don't wanna tag on an extra 2..5 MB Gui-Library to my model-code / backend...
Just my 2 cent's worth
Regards Benny

eta: Have you had a 'looksee' at Michael's 'Fresnel' project?!?
Title: Re: TBCFluentProgressRing bug
Post by: hedgehog on May 13, 2025, 01:59:51 pm
Quote from: cdbc on May 13, 2025, 12:51:08 pm
eta: Have you had a 'looksee' at Michael's 'Fresnel' project?!?

This?
https://www.blaisepascalmagazine.eu/14190-2/ (https://www.blaisepascalmagazine.eu/14190-2/)

Update:
Hmm, the authors of this framework write almost the same thing!
Quote
The design of the VCL and LCL is old. In the browser, UX and UI have evolved far beyond
what the LCL has to offer, largely thanks to the strength of CSS.
Title: Re: TBCFluentProgressRing bug
Post by: circular on May 15, 2025, 11:35:25 pm
I agree that BGRAControls has a wide range of styles, at least by default. There has been some efforts with themes, though.
Title: Re: TBCFluentProgressRing bug
Post by: lainz on May 16, 2025, 02:55:27 am
The problem is defining a control that fits everything. Images, svg, drawings, animations. With themes is possible to an extent. With controls like bcbutton we can do cascading with json.

If we can stop and start everything again say in bgracontrols new version from the very beginning the first we need to do is design the code in a way all controls are the same look and feel.

Like drawing an OS theme with all possible controls. The package custom drawn that comes with Lazarus had that in mind.

The other problem is keeping up to date the controls. With every new Mac and Windows version they create a new standard.

We can do that theme and new controls reusing code. But anyways is a big task.

What do you think is better. Themes or objects with a lot of properties?

My favorite control is bcbutton but that code is hard to handle. It has json with cascading even if no one uses that. Is the most similar to css we have.

In the other hand we have themes that I find hard to manage in a large application like having to duplicate the images for the svg list and duplicate the theme settings in every form.

So I think is better bcbutton way and the most simple to understand and use. We can set the theme with code and apply it for the entire application.

I like the idea of creating a new set of controls that follow some rules instead of having a lot of duplicate controls that don't fit every usage cases. And controls that follow a style that cannot be used in combination with the other controls.

Of course we don't have a map to create bgracontrols but for the future I wish we have.

Instead of 10 different buttons a single one that can handle all the styles.
Title: Re: TBCFluentProgressRing bug
Post by: lainz on May 16, 2025, 03:23:37 am
I'm adding a fragment of a conversation I'm having with circular because I resume better the goals I have in mind:

Leandro Diaz:
Hi. I've commented the fluent ring bug in the forum.

Basically I'm interested in creating a new better bgracontrols designed with more mind and care.

To create that we need to define a style object with all the possibilities.

Images. Svg. Drawing.

With that style we can draw anything needed.

The controls will look the same with the same style.

No more duplicate controls to have different styles or functions.

Do you have some idea of for example how we can define such style object?

Like text and shadows. Shadows for the shapes. Images with 9 slice scaling. Svg.

Gradients.

The properties and how to draw that. Then all the controls use the same style object and doesn't have to care about how to draw. We can draw the style in the canvas or bitmap easily.

Functions like draw background. Draw image (svg or bitmap with 9 slice scaling). Draw text. With these 3 drawings we have all done.

For example to draw a progress bar we define 3 style objects. Background, progress and text.

To draw a button we define normal, hover, active, focused, disabled.

Text

Nothing more. The control is done in minutes with the style object.

The style object decides what to draw. If a bitmap. An svg or a custom drawing.

So instead of having 3 themes one for bitmaps, other for svg and other for custom drawing we have all in one

Is like a lazpaint for drawing controls.
Title: Re: TBCFluentProgressRing bug
Post by: lainz on May 16, 2025, 03:53:22 am
I think css is the wheel I'm reinventing  :D
Title: Re: TBCFluentProgressRing bug
Post by: lainz on May 16, 2025, 04:08:23 am
https://wiki.freepascal.org/Fresnel
Title: Re: TBCFluentProgressRing bug
Post by: hedgehog on May 16, 2025, 07:12:59 am
If it's acceptable, I'll speak up.

Never base your control design on native controls from different operating systems. There are dozens of them! You can drown in them.

I think that the examples to follow are MaterialDesign from Google and FluentDesign from Microsoft. Of course, not in the sense that they should be blindly copied.

The main thing is movement and translucency. It is necessary to develop a standard animation mechanism in BGRA that takes into account the physics of movement.

Shadows and gradients, in my opinion, are not relevant at the moment.

I suggest cutting out some of the messages from here and creating a new topic, for example "BGRAControls roadmap"
Title: Re: TBCFluentProgressRing bug
Post by: circular on May 16, 2025, 11:27:35 am
Thanks for sharing your view. Personally, I think it's perfectly valid to use native controls and base extended control design on them. In fact, this approach has clear advantages: being the most optimized in terms of CPU and memory usage. However, it's not the only path forward. What you suggest is close to what has already been explored (see for example the test/test_md* in the BGRAControls repository).

There are various opinions and needs on the subject, and we're clearly in a complex situation with three broad directions:
Regarding the Fresnel project, I think it's a beautiful and ambitious idea. However, it does shift us away from the small-footprint, efficiency-focused path traditionally favored. That's fine, but it may not appeal to everyone. For example, CSS, while flexible, is not particularly efficient (parsing text with complex rules) and though Skia is a solid graphics engine, it brings a footprint of about 20 MB.

Another important factor is the state of GTK support. GTK3 remains problematic, and GTK2 is deprecated by major distributions like Debian. This puts pressure on the LCL's promise of portability. In that context, Fresnel might have better odds of success, since it only needs to handle a subset of OS features. It's good to see this project offer an alternative path.

Ultimately, none of these directions are simple. They will likely coexist for some time. The key question is where to focus our efforts. It seems that here, we lean toward the first option. To keep the project manageable, I agree with your point: we should aim for simplicity and focus on implementing only what's truly needed.

In terms of backward compatibility, it's probably best to keep BGRAControls as it is, a place to experiment with new controls. Breaking existing controls could disrupt current projects that rely on them. It's great to have a stable foundation and a sandbox for innovation.

We could create a new package for future development. But instead of rushing to replicate or import controls from BGRAControls, we should take the time to carefully design its structure. As you suggest, it's a delicate balance: keeping things simple while providing modern, expected features.

That said, we do need at least one person who can dedicate time to ensure consistency throughout the project. Personally, I don't have the bandwidth for that role. Ideally, someone who actively uses these controls in a real project would be a good candidate: they would encounter practical issues regularly and gain valuable insights from hands-on experience.

The project is feasible. A lot of the features we're aiming for are already demonstrated in BGRAControls. Shadows and gradients, for instance, are not technically difficult, we already have what's needed to render them. While we can postpone their implementation at first, we should still design with them in mind, so everything fits together coherently from the beginning.
Title: Re: TBCFluentProgressRing bug
Post by: lainz on May 16, 2025, 02:57:30 pm
Quote
That said, we do need at least one person who can dedicate time to ensure consistency throughout the project. Personally, I don't have the bandwidth for that role. Ideally, someone who actively uses these controls in a real project would be a good candidate: they would encounter practical issues regularly and gain valuable insights from hands-on experience.

I don't have the time too. So must be another contributor.

I'm not changing bgracontrols in the project I work because not perfect but it works (TM).
Title: Re: TBCFluentProgressRing bug
Post by: lainz on May 17, 2025, 05:01:29 am
BTW there's chromium embedded framework for fpc. So why reinventing the wheel if we can have full html and css?
Title: Re: TBCFluentProgressRing bug
Post by: circular on May 17, 2025, 09:45:24 am
Hi hedgehog,

You mentioned that GitHub still feels like a mystery. I'd be happy to get you over the first hurdles. Git can look intimidating, but the day-to-day basics are surprisingly quick to learn.
Title: Re: TBCFluentProgressRing bug
Post by: circular on May 17, 2025, 09:54:34 am
Quote from: lainz on May 17, 2025, 05:01:29 am
BTW there's chromium embedded framework for fpc. So why reinventing the wheel if we can have full html and css?
That's a good point. That is a way for option 3. Looking at the examples, though, it does seem a bit complicated to access the content of the page programmatically. Actually there are various projects to display HTML : https://wiki.lazarus.freepascal.org/Webbrowser
TinyPortal © 2005-2018