On Wed, 19 Feb 2025 13:16:40 -0500 Zinful <zinfulperso...@gmail.com> said:
> Thank you all for your help and suggestions I really I appreciate it. So > the project is sorta weird cause the whole idea is to have a working, fast, > and smooth GUI-like environment on a raspi-0. I wanted to do it that way to > force myself to work low-level and manage resources carefully (like drawing > the mouse directly instead of an icon or sprite). Well i suggested a "soft sprite". not a hardware one (e.g. a hw cursor or hardware plane). you'll learn something in the process, but the way you do sprites is really just compositing (with alpha channel and/or mask or bitmap mask) on top of another set of pixels that represent the screen content below. i could go into all the wonders of many hardware layers and compositing engines or for that matter entire scene graph engines (i've written a relatively big one that runs entire toolkits and compositors and is essentially a sprite engine on a few boatloads of steroids). I'm trying to keep it simpler for you so you can learn some of the core concepts and then be able to build on top or recycle later. > I'm going to have to use Carsten's idea though since dealing with different > endians and getting the mouse to draw/replace its previous position with > the correct color seems like an almost impossible task. It works perfectly > with a 1 pixel size mouse but anything above that it fails to replace with > the proper color > > The resource constraint is also why I'm not using xorg-dev or other high > level libraries. But I like the sprite idea, I just have to render it first > and find a convenient way to move it around. Going with a double buffer > approach (I don't know much yet I'm assuming) I'm pretty sure I can update > sections of the screen instead of replacing the entire screen every > mouse-position movement correct. i am assuming at this stage you'd have 1 offscreen memory buffer for the screen. you'd then copy a small regio of that to a temporary composition buffer where the mouse pointer goes. you'd now composite the pointer on top (using alpha channel or mask) then copy this small region to the screen. it won't be perfect. you will see tearing at times, but this is easily then extended to double buffering and zero-copy swaps later when you figure that out. you can in future replace this composition of the pointer with controlling as hardware cursor overlay instead. but you'll now know what overlays do for you as you've had to do it yourself. if something updates the off-screen "screen buffer" you copy the updated region to the real screen. if the pointer intersects that region you copy those intersected regions as above to temporary buffers, composite the pointer into that then copy this to the real screen. you'll have a smooth experience with a pointer that doesn't flicker and can be any image you provide. > I'll have to find out once I dig into it though. I know the main issue with > the current mouse is that I'm essentially just manipulating memory so > getting the previous byte, at the right time, and especially in the right > order, might be too complex math-wise to be worth it overall see above. separate buffers for different layers of content. combine them then copy to screen. you can always remove the "copy to screen" with double buffered (or triple) zero-copy swaps later. using kms and atomic mode switching you will be able to do tear-free, flicker-free and zero copy display then. the good thing is this technique works just about anywhere. it can work in a window in x, wayland or any other OS. it doesn't rely on a real framebuffer with atomic swaps. to speed up development you can abstract these parts of the pipeline and develop everything else "in a window" on your current desktop ... then when on the target platform you simply use a different buffer present path. > Essentially I'm stubborn and am doing things the hard way cause I don't > know any better yet lol :) Well as Enrico was beginning to point out - there will have been plenty of people who have solved this problem many times over well ahead of you and created libraries and/or compositors and so on that do this for you. That is what the venerable Xorg actually does for you. It's what wayland compositors do for you. It's what libraries like EFL can just hide and do for you. But you won't learn if you just take the existing solution... it's amazing what you learn when you re-invent the wheel. Also you will just not have the sense of accomplishment unless you do it the hard way yourself. I encourage you to stick to it and learn. Make mistakes. Ask for some pointers/advice. In the end you'll be a better developer. > On Wed, Feb 19, 2025, 3:59 AM Carsten Haitzler <ras...@rasterman.com> wrote: > > > On Wed, 19 Feb 2025 09:20:45 +0100 "Enrico Weigelt, metux IT consult" > > <i...@metux.net> said: > > > > > On 18.02.25 08:12, Carsten Haitzler wrote: > > > > > > > Advice - don't try and just bolt on a mouse with a hack. reality is to > > do a > > > > mouse, you're doing sprites/overlays and/or compositing (to do it > > right) so > > > > instead of bolting it on with a hack, bite the bullet and work out how > > to do > > > > some proper compositing of images (sprites) off-screen with also > > retained > > > > off-screen content of the screen then transfer any changes on to the > > screen > > > > when done. > > > > > > Actually, raw fbdev isn't the right choice for such things - unless one > > > really hasn't any other choice. > > > > > > DRM has support for such things, easy to use via libdrm: > > > https://github.com/metux/twtk/blob/master/src/platform/drm.c > > > > why i mentioned going to swaps (i was implying you'd end up with kms etc.) > > but > > fbdev is a simple way to learn the basics of what a framebuffer is and how > > to > > possibly fill it with content. moving to a nice multi-buffer swapping > > mechanism > > is another stage in the learning... :) > > > > > I'd also recommend using some existing library for drawing (eg. cairo). > > > > i actually suspect that learning something about drawing/rendering and so > > on is > > part of the task... so as a college project ... it's better to DIY with > > some > > cpu compositing to learn it all.. :) what you do to learn and what you do > > to > > get a quick result will be different :) > > > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > > > > Indeed ;-) > > > > > > > > > --mtx > > > > > > -- > > > --- > > > Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert > > > werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren > > > GPG/PGP-Schlüssel zu. > > > --- > > > Enrico Weigelt, metux IT consult > > > Free software and Linux embedded engineering > > > i...@metux.net -- +49-151-27565287 > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > Carsten Haitzler - ras...@rasterman.com > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com
