this post was submitted on 04 Jun 2024
658 points (98.5% liked)
Technology
58692 readers
3876 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Hilarious to me that it OCRs the text. The text is generated by the computer. It's almost like when Lt. Cmdr. Data wants to get information from the computer database, so he tells the computer to display it and just keeps increasing the speed
there are way more efficient means of getting information from A to B than displaying it, imaging it, and running it though image processing!
I totally get that this is what makes sense, and it's independent of the method/library used for generating text, but still...the computer "knows" what it's displaying (except for images of text), and yet it has to screenshot and read it back.
Having worked on a product that actually did this, it's not as easy as it seems. There are many ways of drawing text on the screen.
GDI is the most common, which is part of the windows API. But some applications do their own rendering (including browsers).
Another difficulty, even if you could tap into every draw call, you would also need a way to determine what is visible on the screen and what is covered by something else.