bruce965

joined 2 years ago
[–] bruce965@lemmy.ml 1 points 4 days ago

I'm definitely no expert so I might not be the best person to try and help, but if you want to try having a 1 on 1 chat to fix it, feel free to send me a PM.

[–] bruce965@lemmy.ml 3 points 4 days ago (2 children)

Can you see at least GRUB, or nothing at all?

If you can see GRUB I would try booting with the "nosplash" kernel option, which causes video drivers to be loaded later.

This is a temporary fix, as it might cause other issues, but if it makes the screen work it will be a step in the right direction.

[–] bruce965@lemmy.ml 1 points 6 days ago

I am not sure... in the case I'm referring to, they were lagging also when scrolling. But it was React, so native browser rendering. And they were actually very large tables, so we had to do some funny things like viewport culling (see react-window).

For what it's worth I've never had any similar performance issues with tables in Flutter (web with the canvas-based render engine, not Android) when applying the same culling technique, they just ran fine at any resolution. Different hardware, though, so it's not an apple to apple comparison.

In any case just to be safe I would personally assume less pixels = less work = less power = more battery life. My opinion is very unscientific though.

[–] bruce965@lemmy.ml 1 points 6 days ago* (last edited 6 days ago) (1 children)

Isn't rescaling usually done by the display driver? I am fairly certain this is the case for external displays. Are laptop displays any different?

Edit: with "display driver" I mean the hardware chip behind the display panel, dedicated to converting a video signal to the electrical signals necessary to turn on the individual pixels.

[–] bruce965@lemmy.ml 2 points 6 days ago (2 children)

As a web developer, I noticed that some elements such as very big tables struggle to render on 4K but are absolutely fine at 1080p. I would assume that means the CPU and/or GPU are more taxed to draw at higher resolution, and therefore I assume they would draw more power. I might be mistaken. Do you speak by experience?

[–] bruce965@lemmy.ml 1 points 1 week ago

Good separation between business logic and UI without effort, cross-platform UI in any language, possibility to turn it into a web-accessible service in the future, great choice of UI frameworks and battle-tested components if you decide to go for a web framework and language.

As an example of a successful software that followed this approach: Synchthing. All versions run a local web service in the background. The Desktop version just opens a browser on the index page. The Android version is a native app that calls the exposed REST API on localhost, bypassing the web UI.

As an example of a much more complex software, albeit not FOSS: EasyEDA. It's a web software, but it also comes as a desktop app (which I never tried) which I assume is not much more than a frame for the web view.

My recommendation: write the UI with React on Vite in TypeScript, and write the business logic in your general purpose language of choice (mine would usually be C#).

[–] bruce965@lemmy.ml 1 points 1 week ago (2 children)

If it makes sense for your software, please consider giving it a web interface and turning it into a localhost-only web-service.

[–] bruce965@lemmy.ml 3 points 2 weeks ago* (last edited 2 weeks ago)

I might be very mistaken, but I don't think QEMU can link mixed-architecture dependencies. Box86 can run an x86 game on ARM and link ARM-native shared objects for OpenGL, thus skipping emulation of some hotpath code.

[–] bruce965@lemmy.ml 14 points 3 weeks ago (4 children)

VM startup time can be skipped by saving state instead of shutting it down every time.

I would say the worst issue using a VM is with programs that need the GPU (e.g. CAD softwares or games), and software with aggressive DRM.

[–] bruce965@lemmy.ml 33 points 1 month ago* (last edited 1 month ago)

I use DDG for the privacy as well, but personally I think it works better than Google in my field (software development). The only issue I personally have with DDG is that it lags behind Google in terms of updates, I notice when searching for something that came out or happened only recently.

[–] bruce965@lemmy.ml 1 points 1 month ago* (last edited 1 month ago)

I thought so. Although almost nothing for modern standards, 60MB is not exactly tiny. Sorry about that.

On a different note, a repository is always a good thing imho. If you'd rather not have to worry about the dependency-pull step you can always include the dependencies with your sources, or just limit your code to using features included in the standard library.

[–] bruce965@lemmy.ml 5 points 1 month ago* (last edited 1 month ago) (3 children)

JavaScript through Node.js, or TypeScript through Deno if you like typed languages. They both check all your boxes (just check the size of the executables to make sure that it's what you would consider "small footprint").

Both languages and runtimes are quite popular, so you will find any answers on StackOverflow.

They are both single-executable with little dependencies, and Deno can also compile your scripts to self-contained executables.

As a bonus, both support the vast and extensive NPM package repository where you can find all sort of libraries for even the most complex tasks.

And they work with your favourite IDE or editor, not just syntax highlighting, but also contextual suggestions.

 

Yesterday, Spacemesh started circulating. Do you know about it? What do you think about it?

I have written this brief blog post to explain how it is different from other mainstream cryptos. Let me know if you have any questions.

(Also, this is my first post on Lemmy!)

view more: next ›