LCUI
LCUI copied to clipboard
lc-soft
Add FPS meter
Is your feature request related to a problem? Please describe.
We need a graphical user interface to display the current rendering state to debug performance issues.
Describe the solution you'd like
Refer the Chrome Browser:
This is the list of requirements:
- [ ] Mode
- [ ] Normal: show all content
- [ ] Minimized: only show fps and chart, refer: https://darsa.in/fpsmeter/
- Note: The mode should be switched when clicking it.
- [ ] Charts
- [ ] Chart widget: receive an array of integers and draw them into a bar chart, it should inherit from canvas widget
- [ ] FPS chart: show the number of frames updated every second
- [ ] Widget updates chart: show the number of components updated every second
- Note 1: If nothing is rendered in the current frame then the fps chart should not be updated
- Note 2: All statistics should ignore the effect of the fps meter
- [ ] Labels
- [ ] Frame Rate
- [ ] fps: ${fps} fps
- [ ] fps range: 1-${settings.frame_rate_cap}
- [ ] Parallel rendering threads: ${used}/${total}
- [ ] Updates
- [ ] Updated: ${updatedWidgets}
- [ ] Total: ${totalWidgets}
- Note: The semantics of these labels may not be clear, you can improve it.
- [ ] APIs
- [ ] Add APIs to collect the above data
- [ ] Update the existing APIs to collect the above data
- Note: This work requires many reviews and changes to meet the author's expectations.
- [ ] Use fps meter instead of fps textview in test/test_render.c
Additional context
How to draw a chart?
You need these:
- i
- x, y
- fps_data
- LCUIWidget_NewPrototype("fps-meter-chart", "canvas")
- Canvas_GetContext()
for (x = 0; i < fps_data_length; ++x)- CanvasContext_FillRect()
I believe you have guessed the implementation method through these keywords.
What does it look like?
I have written css and html code, you can refer to it:
https://codepen.io/lc-soft/pen/NWxYpGv?editors=1100
The effect of the bar chart should be the following:
https://darsa.in/fpsmeter/
IssueHunt Summary
Backers (Total: $185.10)
lc-soft ($185.10)
Become a backer now!
Or submit a pull request to get the deposits!
Tips
- Checkout the Issuehunt explorer to discover more funded issues.
- Need some help from other developers? Add your repositories on IssueHunt to raise funds.
@lc-soft has funded $15.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
![issuehunt-oss[bot] avatar](https://avatars.githubusercontent.com/in/29881?v=4 "Published by a pub.dev verified publisher"){kind=small}
@lc-soft has funded $10.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
@lc-soft has funded $10.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
@lc-soft , I can take a look at this. Would it make more sense to have this PR build upon the solution to #191, which I've already made a fair amount of progress on? That work cleans up the profiling code a bit as well as makes the thread count easy to access.
@lc-soft , I can take a look at this. Would it make more sense to have this PR build upon the solution to #191, which I've already made a fair amount of progress on? That work cleans up the profiling code a bit as well as makes the thread count easy to access.
Please wait a moment, just now I was thinking about finishing this work when I have time in the future.
@jduo
The description of this issue needs to be updated. I plan to redesign the requirements of this feature in the future, so please do not consider working on this issue for the time being. Moreover, $100 has exceeded my budget.
@lc-soft , this should be re-opened. The settings API commit accidentally referenced this.
@jduo @jananiram
The description of this issue has been updated, please re-evaluate its workload, and then update the bounty request.
@jduo
I think issue #192 is much simpler than issue #210, because the workload of issue #210 is more than 10 times that of issue #192, but from your bounty request, the workload of issue #192 seems to be larger than I expected.
Does this mean Are you planning to make a lot of changes to related code for issue #192? Or is issue #210 simpler than I thought? Please briefly explain your work plan for issue #192。
It's mostly the comment "Note: This work requires many reviews and changes to meet the author's expectations." that made me decide to up the bounty on this one from the original $100 I had put up. It was a bit open-ended.
@lc-soft has funded $6.10 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
@lc-soft has funded $144.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
@jduo I have increased the bonus from $35 to $185.10, and you can start doing it.
There are three fees in payment, reward and withdrawal: stripe fee (3.74%), service fee (10%), transaction fee (3.6%), I think the fees charged are too much.
I've started work on this. A few questions:
- Should the number of elements in the chart be fixed? Should it be configurable? Should it be dynamic based on the size of the window?
- Can you point me to an existing widget that inherits from canvas? Do you mean the chart widget should be composed of a canvas widget, such that function calls such as init, onpaint, etc delegate to the canvas widget?
- Should the chart update every second? The gif updates much more quickly than this. Is every point in the chart a capture of the frame count at a second? I guess the array the chart is built off of needs to be a circular array so that we can add new values without losing previous ones.
- My thinking is that we have a Metrics widget, which holds an FPS meter widget + Widget update stats widget, and the FPS meter widget/widget update stats widget both maintain a chart widget. The application can just construct the Metrics widget. The Metrics widget is responsible for handling changing of the mode between normal/minimized.
- Should the number of elements in the chart be fixed? Should it be configurable? Should it be dynamic based on the size of the window?
Do you mean the number of bars in the chart? I suggest that you calculate the appropriate number of bars based on the width of the chart, for example:
number_of_bars = bar_chart.width / bar_width;
- Can you point me to an existing widget that inherits from canvas? Do you mean the chart widget should be composed of a canvas widget, such that function calls such as init, onpaint, etc delegate to the canvas widget?
I have written a spinner widget based on canvas widget before, you can refer to it:
https://github.com/lc-ui/lc-design/blob/f824ca5ad6766554312eca44b904ceb5f5cffab7/src/ui/components/spinner.c#L247-L256
The core code is as follows:
LCUI_SetInterval(LCUI_MAX_FRAME_MSEC, (TimerCallback)Spinner_OnFrame, w);static void Spinner_OnFrame(LCUI_Widget w)static void Spinner_Render(LCUI_Widget w)LCUI_CanvasContext ctx = Canvas_GetContext(w);ctx->clearRect(ctx, 0, 0, ctx->width, ctx->height);FillPixel(&ctx->buffer, xi, yi, &c);Widget_InvalidateArea(w, NULL, SV_CONTENT_BOX);ctx->release(ctx);
Should the chart update every second? The gif updates much more quickly than this.
Yes, you only need to refer to the style of the bar in the gif, no need to pay attention to the update speed.
Is every point in the chart a capture of the frame count at a second?
Yes.
I guess the array the chart is built off of needs to be a circular array so that we can add new values without losing previous ones.
I suggest using a linked list to save the frame count, the pseudo code is as follows:
LinkedList frameCountList;
// insert new frame count into head
frameCountList.unsift(currentFrameCount);
if (frameCountList.length > maxLen) {
// delete last frame count
frameCountList.pop();
}
- My thinking is that we have a Metrics widget, ...
I think it's okay, but I want the names of these three widgets to have the fps-meter- prefix.
- Should the number of elements in the chart be fixed? Should it be configurable? Should it be dynamic based on the size of the window?
Do you mean the number of bars in the chart? I suggest that you calculate the appropriate number of bars based on the width of the chart, for example:
number_of_bars = bar_chart.width / bar_width;
Would bar_width be fixed then? Or would it scale with the size of the window? Actually should the chart even be resizable?
- My thinking is that we have a Metrics widget, ...
I think it's okay, but I want the names of these three widgets to have the
fps-meter-prefix. I feel the chart component could potentially be reusable outside of the context of the fps-meter, but I guess we could always rename it.
In your example showing CSS/HTML at https://codepen.io/lc-soft/pen/NWxYpGv?editors=1100 Should the CSS you've shown here be passed into LCUI_LoadCSSString()?
Should the CSS you've shown here be passed into LCUI_LoadCSSString()?
@jduo Yes, you can use this css code directly and make the widget tree structure the same as the html code.
Would bar_width be fixed then? Or would it scale with the size of the window?
it should scale with the size of the window, I think this problem is easy to solve, just recalculate the bar_width before each drawing and then draw them with the new bar_width.
Actually should the chart even be resizable?
Yes, this chart widget may be used elsewhere in the future, and you should make it adaptable to any size as much as possible.
Would bar_width be fixed then? Or would it scale with the size of the window?
Actually should the chart even be resizable?
@jduo I thought about it, you can use a fixed width for bar. because there is no need to make the width of the bar scalable, in order to adapt to the large size, we can increase the number of bars instead of increasing the bar width.
Hi @lc-soft , Was trying to test a build of the widget and noticed the tutorial link was broken here: https://lcui.org/guide/
Quick question, does LCUI create a relationship between CSS properties and struct fields for widgets? Or is that part of the widget implementation?
@jduo
There is no English version of this tutorial, and I will replace the tutorial link with https://docs.lcui.lc-soft.io/.
does LCUI create a relationship between CSS properties and struct fields for widgets?
Check here:
https://github.com/lc-soft/LCUI/blob/6656f40a26d35283b4936203409f3b6119ec4c0b/include/LCUI/gui/widget_base.h#L287-L302
The stylesheet of the widget will be updated here:
https://github.com/lc-soft/LCUI/blob/029984eb173f244803336f94ceb0f194f941c698/src/gui/widget_task.c#L203-L215
CSS properties will be recalculated when they change and their actual values will be saved in LCUI_Widget::computed_style.
https://github.com/lc-soft/LCUI/blob/029984eb173f244803336f94ceb0f194f941c698/src/gui/widget_task.c#L175-L196
Hi @lc-soft , I got sidetracked for a bit. Plan to come back to this issue next week.
Hi @lc-soft , I got sidetracked for a bit. Plan to come back to this issue next week.
OK, If you think this project has some incomprehensible code, please feel free to ask me.
Hi don't know if I can do this, but is this still available?
@Interdice It is temporarily unavailable because the new version under development has many changes, and it needs to wait until the new version is released.