Hello,
If that helps:
OS: macOS (Tahoe 26.5.2)
Hardware GPU: Apple M1 8GB
Go Version: 1.25.0 (using the repo's go.mod version)
Framework Versions:
github.com/gogpu/gg v0.52.3
github.com/gogpu/gogpu v0.53.0
github.com/gogpu/gpucontext v0.28.0
github.com/gogpu/gputypes v0.5.2
github.com/gogpu/wgpu v0.31.4
I'm just getting to know the project and was looking around the IDE example, since it's the most similar example relevant to my use case.
I just happened to find a few bugs, and I don't know if they're just bugs in the example code or if it could be the case they're bugs in the gogpu or ui internal code or widgets.
I'm just opening the issue to inform, and if I have the chance during the weekend or next week, I'll investigate further and perhaps try to contribute.
When clicking the "Maximize" button, the program hangs forever.
The button has the visual of "disabled" as it's quite faded, but it's still clickable, dangerously.
It is the case that the IDE example, while doing absolutely nothing, consumes almost 300MB of memory, uses 20 threads and read 60MB from the disk...
Is this expected?
Because I understand the idea of gogpu is to be "lower level" and efficient, no?
300MB for a static UI that doesn't even have that many widgets and absolutely nothing going on doesn't sound right or perhaps I'm mistaken about the project purpose.
And apart from that, of course, it hanged.
Other bugs include, clicking file names in the file tree actually either select the wrong file or select multiple files at the same time, I can see in the logs that I click one file, and it prints to stdout the name of the clicked file, a few others, and the blue selection might actually end up in another completely different file in the UI.
Sometimes by clicking in a few tabs, either "file tabs" in the top, or the bottom tabs (terminal and output), the UI resizes the column and the mouse cursor assumes the resize pointer and function.
It happens non-deterministically, if you resize the column, and cycle between clicking the Terminal and Output tabs three or four times, the bug might happen.
Do you believe that's a bug in the Widgets themselves, or just a poorly written example (probably AI I would guess)?
I'll try to investigate in the weekend but I'm asking so that perhaps I can get a hint if you saw some of those bugs before in other examples or using the library elsewhere.
Hello,
If that helps:
OS: macOS (Tahoe 26.5.2)
Hardware GPU: Apple M1 8GB
Go Version: 1.25.0 (using the repo's go.mod version)
Framework Versions:
github.com/gogpu/gg v0.52.3
github.com/gogpu/gogpu v0.53.0
github.com/gogpu/gpucontext v0.28.0
github.com/gogpu/gputypes v0.5.2
github.com/gogpu/wgpu v0.31.4
I'm just getting to know the project and was looking around the IDE example, since it's the most similar example relevant to my use case.
I just happened to find a few bugs, and I don't know if they're just bugs in the example code or if it could be the case they're bugs in the gogpu or ui internal code or widgets.
I'm just opening the issue to inform, and if I have the chance during the weekend or next week, I'll investigate further and perhaps try to contribute.
When clicking the "Maximize" button, the program hangs forever.
The button has the visual of "disabled" as it's quite faded, but it's still clickable, dangerously.
It is the case that the IDE example, while doing absolutely nothing, consumes almost 300MB of memory, uses 20 threads and read 60MB from the disk...
Is this expected?
Because I understand the idea of gogpu is to be "lower level" and efficient, no?
300MB for a static UI that doesn't even have that many widgets and absolutely nothing going on doesn't sound right or perhaps I'm mistaken about the project purpose.
And apart from that, of course, it hanged.
Other bugs include, clicking file names in the file tree actually either select the wrong file or select multiple files at the same time, I can see in the logs that I click one file, and it prints to stdout the name of the clicked file, a few others, and the blue selection might actually end up in another completely different file in the UI.
Sometimes by clicking in a few tabs, either "file tabs" in the top, or the bottom tabs (terminal and output), the UI resizes the column and the mouse cursor assumes the resize pointer and function.
It happens non-deterministically, if you resize the column, and cycle between clicking the Terminal and Output tabs three or four times, the bug might happen.
Do you believe that's a bug in the Widgets themselves, or just a poorly written example (probably AI I would guess)?
I'll try to investigate in the weekend but I'm asking so that perhaps I can get a hint if you saw some of those bugs before in other examples or using the library elsewhere.