Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #57246 > unrolled thread

reading / writing the color of an absolute pixel (x,y) of the physical screen

Back to article view | Back to alt.os.linux

Contents

  reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-25 17:53 +0200
    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Alfonso P Cutaway <dweed54@gmail.com> - 2019-06-25 16:01 +0000
      Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "R.Wieser" <address@not.available> - 2019-06-25 19:03 +0200
        Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Alfonso P Cutaway <dweed54@gmail.com> - 2019-06-25 18:08 +0000
          Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "R.Wieser" <address@not.available> - 2019-06-25 21:44 +0200
            Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Alfonso P Cutaway <dweed54@gmail.com> - 2019-06-26 00:37 +0000
              Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "R.Wieser" <address@not.available> - 2019-06-26 10:50 +0200
                Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Alfonso P Cutaway <dweed54@gmail.com> - 2019-06-26 19:43 +0000
                  Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "Carlos E.R." <robin_listas@es.invalid> - 2019-06-26 22:37 +0200
                    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Alfonso P Cutaway <dweed54@gmail.com> - 2019-06-26 20:55 +0000
                      Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "Carlos E.R." <robin_listas@es.invalid> - 2019-06-26 23:29 +0200
                  Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Aragorn <thorongil@telenet.be> - 2019-06-26 23:50 +0200
                    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Alfonso P Cutaway <dweed54@gmail.com> - 2019-06-26 22:50 +0000
                    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen DecadentLinuxUserNumeroUno@decadence.org - 2019-06-28 12:50 +0000
                      Re: reading / writing the color of an absolute pixel (x,y) of the physical screen DecadentLinuxUserNumeroUno@decadence.org - 2019-06-28 12:56 +0000
                  Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "R.Wieser" <address@not.available> - 2019-06-27 11:10 +0200
                    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-27 12:39 +0200
                      Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "R.Wieser" <address@not.available> - 2019-06-27 14:43 +0200
                        Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-27 15:57 +0200
          Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 01:03 +0200
            Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Alfonso P Cutaway <dweed54@gmail.com> - 2019-06-26 00:38 +0000
    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Wildman <best_lay@yahoo.com> - 2019-06-25 11:18 -0500
      Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 01:02 +0200
        Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Aragorn <thorongil@telenet.be> - 2019-06-26 01:08 +0200
    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Bit Twister <BitTwister@mouse-potato.com> - 2019-06-25 11:48 -0500
    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Paul <nospam@needed.invalid> - 2019-06-25 16:14 -0400
      Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 01:13 +0200
        Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "F. Russell" <fr@random.info> - 2019-06-26 08:37 +0000
          Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 12:29 +0200
            Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Bit Twister <BitTwister@mouse-potato.com> - 2019-06-26 06:55 -0500
            Re: reading / writing the color of an absolute pixel (x,y) of the physical screen "F. Russell" <frussell@random.info> - 2019-06-26 12:15 +0000
            Re: reading / writing the color of an absolute pixel (x,y) of the physical screen owl <owl@rooftop.invalid> - 2019-06-26 12:35 +0000
              Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 15:44 +0200
                Re: reading / writing the color of an absolute pixel (x,y) of the physical screen owl <owl@rooftop.invalid> - 2019-06-26 14:00 +0000
                  Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 21:01 +0200
                    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen owl <owl@rooftop.invalid> - 2019-06-26 23:05 +0000
                      Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-27 12:27 +0200
                        Re: reading / writing the color of an absolute pixel (x,y) of the physical screen owl <owl@rooftop.invalid> - 2019-06-27 13:53 +0000
    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Jasen Betts <jasen@xnet.co.nz> - 2019-06-26 10:13 +0000
    Re: reading / writing the color of an absolute pixel (x,y) of the physical screen Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 12:49 +0200

Page 2 of 2 — ← Prev page 1 [2]

#57262

On Wed, 26 Jun 2019 01:03:21 +0200, Soviet_Mario wrote:

> On 25/06/19 20:08, Alfonso P Cutaway wrote:
>> On Tue, 25 Jun 2019 19:03:48 +0200, R.Wieser wrote:
>> 
>>> Al,
>>>
>>>> Attention....this Mario poster is a bot,
>>> ....
>>>> and left in a huff
>>>
>>> That does not compute.   Bots (still) do not have feelings, and as
>>> such do not leave "in a huff".
>>>
>>>> Please ignore this Soviet Mario bot and it's ridiculous questions
>>>
>>> Pray tell, what is "ridiculous" about wanting to do some low-level
>>> (fast) pixel manipulation ?
>>>
>>> What is the chance that you are (maliciously) trolling ?
>>>
>>> Regards,
>>> Rudy Wieser
>> 
>> Rudy,
>> You will see if Soviet is a bot or not.....just be patient.....
>> 
>> 
> cuban anti-Castrist refugee ? :)
> 
> roll in your hate and have fun
> 
> 
>>

The bot's english is getting better than it was a year ago....



-- 
Silence is golden. Duct tape is silver. Welcome to Hell. Here's your copy 
of Windows.

[toc] | [prev] | [next] | [standalone]

#57248

On Tue, 25 Jun 2019 17:53:27 +0200, Soviet_Mario wrote:

> It might be one of the lowest level "API" of Xwindows or 
> other window manager.
> 
> Can anybody tell me which Libraries to rely on and some 
> synthax to invoke those methods in user code ?
> 
> I suspect Xwindows code source is simply TOO HUGE for me to 
> sieve it and just get out this couple of lowest level 
> functions (and eventual dependencies).
> 
> Maybe I do not even understand the possible risks, as in 
> this topic I still think in term of aged windows versions 
> (there I had to ask for SCREEN handle, then declare the API, 
> invoke API, and resident apis, no need to load anything 
> else, and understand the data type in/out and the _CDECL 
> declspec for ordering of parameters and stack cleanup C-like)
> 
> now Linux is native in C, so I won't have problems in 
> understanding the exchange requirements .... but I 
> completely ignore for example if I would have the RIGHTS 
> (privilege) to invoke function from loaded external 
> libraries and services ... particularly when writing the 
> screen is concerned I'd could possibly mess up other 
> windows, even if temporarily).
> 
> Some reading for suggestion ?
> 
> NOTICE : I do not need a complete program to pickup colors 
> and draw, as it would be amazingly slow. I need to directly 
> call lowest level functions just in use of the graphical 
> system running (which I suppose to be very fast)
> 
> TY

https://stackoverflow.com/questions/4996777/paint-pixels-to-screen-via-linux-framebuffer

-- 
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!

[toc] | [prev] | [next] | [standalone]

#57257

On 25/06/19 18:18, Wildman wrote:
> On Tue, 25 Jun 2019 17:53:27 +0200, Soviet_Mario wrote:
> 
>> It might be one of the lowest level "API" of Xwindows or
>> other window manager.
>>
>> Can anybody tell me which Libraries to rely on and some
>> synthax to invoke those methods in user code ?
>>
>> I suspect Xwindows code source is simply TOO HUGE for me to
>> sieve it and just get out this couple of lowest level
>> functions (and eventual dependencies).
>>
>> Maybe I do not even understand the possible risks, as in
>> this topic I still think in term of aged windows versions
>> (there I had to ask for SCREEN handle, then declare the API,
>> invoke API, and resident apis, no need to load anything
>> else, and understand the data type in/out and the _CDECL
>> declspec for ordering of parameters and stack cleanup C-like)
>>
>> now Linux is native in C, so I won't have problems in
>> understanding the exchange requirements .... but I
>> completely ignore for example if I would have the RIGHTS
>> (privilege) to invoke function from loaded external
>> libraries and services ... particularly when writing the
>> screen is concerned I'd could possibly mess up other
>> windows, even if temporarily).
>>
>> Some reading for suggestion ?
>>
>> NOTICE : I do not need a complete program to pickup colors
>> and draw, as it would be amazingly slow. I need to directly
>> call lowest level functions just in use of the graphical
>> system running (which I suppose to be very fast)
>>
>> TY
> 
> https://stackoverflow.com/questions/4996777/paint-pixels-to-screen-via-linux-framebuffer
> 

intresting thread.
In some comments though they give the recommendation not to 
try to directly use frame buffer but to rely on X11 (maybe 
the same entity I mentioned as Xwindow) APIs ... 
unfortunately the responder did not mention other things 
about this APIs.

Anyway I think I'll give it a try to just READ the screen (I 
know the geometrical resolution, maybe I'll be able to 
deduce the coordinates in the flat file)
Tnx


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57259

On 26.06.2019 at 01:02, Soviet_Mario scribbled:

> X11 (maybe the same entity I mentioned as Xwindow)

Yes, it is the same thing.


-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#57250

On Tue, 25 Jun 2019 17:53:27 +0200, Soviet_Mario wrote:
>
> It might be one of the lowest level "API" of Xwindows or
> other window manager.
>
> Can anybody tell me which Libraries to rely on and some
> synthax to invoke those methods in user code ?

Hmmm, based on your rants on arguments are too cryptic and man pages
are very shy on examples, I can guess it will be a complete waste of
anybody's time to get you to the point of writing code that will compile
let alone link.

For example, you want to copy a sting from one place in memory
to a buffer for output so I'll pick memccpy as an example. Go ahead
and see if you can see what is required for usage.
Hint:    man memccpy

And what compile options will you be using, hint    man gcc

[toc] | [prev] | [next] | [standalone]

#57255

Soviet_Mario wrote:
> 
> It might be one of the lowest level "API" of Xwindows or other window 
> manager.
> 
> Can anybody tell me which Libraries to rely on and some synthax to 
> invoke those methods in user code ?
> 
> I suspect Xwindows code source is simply TOO HUGE for me to sieve it and 
> just get out this couple of lowest level functions (and eventual 
> dependencies).

The best looking graphics come from using libraries.

You can double buffer what you're doing, write your
own buffer (in memory), then call on a graphics card
routine to composite the new pixmap at a specific point
in time. This has the advantage of no screen tearing.

It doesn't have to look like TempleOS.

If you've seen the video of the TempleOS, you'll begin
to appreciate what the screen looks like with no scroll
throttles or buffering schemes.

On modern video cards, you are hardly ever doing anything
as "old fashioned" as the description of what you want to
do. For example, some video cards support security features,
which are there to prevent making exact copies of Hollywood
movies (bypass HDCP from inside the computer).

Even if someone gives you a start address to write the
screen, you're probably still going through layers and
layers of other display code to get there. The Ring model
for computers (Ring 0 and Ring 3) means that you hardly
ever are doing what you think you are doing when you
live in userspace Ring3. Lots of emulations hide the details.

And that's why, for performance reasons, it's better to
write to a private pixmap, and transfer it to the
frame buffer at frame rate. This costs zero for
a modern video card. (It's already doing a gigabyte per
second, just drawing the screen for you. It's also
why we have all that PCI Express bandwidth between
the CPU and the video card.)

*******

These days, the best start when it comes to code, is finding
a sample code using Google. Someone will tell you about
noteworthy calls.

https://www.student.cs.uwaterloo.ca/~cs349/f15/resources/X/xTutorialPart1.html

My Google search terms to find that were:

    xwindows drawing to screen sample code

   Paul

[toc] | [prev] | [next] | [standalone]

#57260

On 25/06/19 22:14, Paul wrote:
> Soviet_Mario wrote:
>>
>> It might be one of the lowest level "API" of Xwindows or 
>> other window manager.
>>
>> Can anybody tell me which Libraries to rely on and some 
>> synthax to invoke those methods in user code ?
>>
>> I suspect Xwindows code source is simply TOO HUGE for me 
>> to sieve it and just get out this couple of lowest level 
>> functions (and eventual dependencies).
> 
> The best looking graphics come from using libraries.
> 
> You can double buffer what you're doing, write your
> own buffer (in memory), then call on a graphics card
> routine to composite the new pixmap at a specific point
> in time. This has the advantage of no screen tearing.
> 
> It doesn't have to look like TempleOS.
> 
> If you've seen the video of the TempleOS, you'll begin
> to appreciate what the screen looks like with no scroll
> throttles or buffering schemes.
> 
> On modern video cards, you are hardly ever doing anything
> as "old fashioned" as the description of what you want to
> do. For example, some video cards support security features,
> which are there to prevent making exact copies of Hollywood
> movies (bypass HDCP from inside the computer).

Oh, I'm not going to do any video graphics, I just need to 
translate some old Visual Basic programs doing some 
specialized tasks, like :
Areas measuring in pictures basing on colour patterns criteria
Applying some kind of watermarks and/or steganographs with 
rather personal modes.

The results can be waited for for tens of seconds to minutes 
with no problems

> 
> Even if someone gives you a start address to write the
> screen, you're probably still going through layers and
> layers of other display code to get there. 

that's not evil for me. A safe access is preferred to brute 
force bypassing most layers.
But reasonably slow.

In Gambas I have partially replicated some features 
(generation of polylinear gradients for backgrounds) but 
only on some container controls and I don't well understand 
the underlying object model for graphics management.

I don't need much pre-optimized library functions, just a 
rectangle to operate on. Actually I just copy the colours 
but the calculations are done in a memory copy with user 
defined structs

> The Ring model
> for computers (Ring 0 and Ring 3) means that you hardly
> ever are doing what you think you are doing when you
> live in userspace Ring3. Lots of emulations hide the details.

Maybe I expressed misleadingly when I spoke of "physical 
screen". I just meant to be able to address any point even 
out of my program window, but not really to access the 
hardware directly. Too unsafe for me to try.

> 
> And that's why, for performance reasons, it's better to
> write to a private pixmap, and transfer it to the
> frame buffer at frame rate. 

In gambas I used a similar approach (not using a pixmap but 
an array of structs with 8 bit depth per each color plus 
alpha channel)

> This costs zero for
> a modern video card. (It's already doing a gigabyte per
> second, just drawing the screen for you. It's also
> why we have all that PCI Express bandwidth between
> the CPU and the video card.)
> 
> *******
> 
> These days, the best start when it comes to code, is finding
> a sample code using Google. Someone will tell you about
> noteworthy calls.
> 
> https://www.student.cs.uwaterloo.ca/~cs349/f15/resources/X/xTutorialPart1.html 
> 

I'm gonna have a look, thanks

> 
> My Google search terms to find that were:
> 
>     xwindows drawing to screen sample code
> 
>    Paul


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57264

On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:

> 
> Oh, I'm not going to do any video graphics, I just need to 
> translate some old Visual Basic programs doing some 
> specialized tasks, like :
> Areas measuring in pictures basing on colour patterns criteria
> Applying some kind of watermarks and/or steganographs with 
> rather personal modes.
> 

Digital image analysis/manipulation is accomplished not by
reading screen pixels but by accessing the image data that
is stored in memory.

The jobs which you describe are best accomplished with
image processing libraries.  There is no need to re-invent
the wheel.

[toc] | [prev] | [next] | [standalone]

#57265

On 26/06/19 10:37, F. Russell wrote:
> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
> 
>>
>> Oh, I'm not going to do any video graphics, I just need to
>> translate some old Visual Basic programs doing some
>> specialized tasks, like :
>> Areas measuring in pictures basing on colour patterns criteria
>> Applying some kind of watermarks and/or steganographs with
>> rather personal modes.
>>
> 
> Digital image analysis/manipulation is accomplished not by
> reading screen pixels but by accessing the image data that
> is stored in memory.
> 

don't add additional unnecessary restrictions.
Sometimes, instead of taking a screenshot of another program 
showing some graphical content (even text well formatted), 
save it to a file, locate and open the file in my program, 
I'd like to go the short way and capturing the rectangle 
directly from the screen.
I tried copy to memory from screen snapshot, but this in 
smart programs (LbO) works fine, myself in Gambas was not 
able to replicate the results, using the "clipboard" object.
I don't know why (I'll inquiry further as it would be an 
acceptable path avoiding creating useless temp files on disk)

I don't know how to politely query another program for its 
client-area window, I just need a bitmap copied

> The jobs which you describe are best accomplished with
> image processing libraries.  There is no need to re-invent
> the wheel.

My wheel was just invented, I just need to recode it for 
another environment (I'm getting bored to use virtual 
machines except from very irreplicable situations), as I 
just have visual basic programs and the base logic was 
enough. The only struggle is "porting", as .NET framework, 
which i relied on, is completely different from here.

To the contrary learning to use external oversized 
libriaries (oversized for my needs, not in general) and at 
last have to rewrite all from scratch will consume far more 
time.

The older I become, the less happy to waste time I have and 
the more in a hurry I feel.

> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57272

On Wed, 26 Jun 2019 12:29:16 +0200, Soviet_Mario wrote:

> Sometimes, instead of taking a screenshot of another program
> showing some graphical content (even text well formatted),
> save it to a file, locate and open the file in my program,
> I'd like to go the short way and capturing the rectangle
> directly from the screen.

Then, I suggest getting the source code for "import" and see how they do it.

[toc] | [prev] | [next] | [standalone]

#57273

On Wed, 26 Jun 2019 12:29:16 +0200, Soviet_Mario write:

> 
> Sometimes, instead of taking a screenshot of another program 
> showing some graphical content (even text well formatted), 
> save it to a file, locate and open the file in my program, 
> I'd like to go the short way and capturing the rectangle 
> directly from the screen.
>

I don't see why, but you need xlib:

https://tronche.com/gui/x/xlib/graphics/XGetImage.html

https://tronche.com/gui/x/xlib/utilities/XGetPixel.html


> 
> My wheel was just invented, I just need to recode it for 
> another environment (I'm getting bored to use virtual 
> machines except from very irreplicable situations), as I 
> just have visual basic programs and the base logic was 
> enough.

Please provide a specific example of what you are attempting
to accomplish.

[toc] | [prev] | [next] | [standalone]

#57276

Soviet_Mario <SovietMario@cccp.mir> wrote:
> On 26/06/19 10:37, F. Russell wrote:
>> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
>> 
>>>
>>> Oh, I'm not going to do any video graphics, I just need to
>>> translate some old Visual Basic programs doing some
>>> specialized tasks, like :
>>> Areas measuring in pictures basing on colour patterns criteria
>>> Applying some kind of watermarks and/or steganographs with
>>> rather personal modes.
>>>
>> 
>> Digital image analysis/manipulation is accomplished not by
>> reading screen pixels but by accessing the image data that
>> is stored in memory.
>> 
> 
> don't add additional unnecessary restrictions.
> Sometimes, instead of taking a screenshot of another program 
> showing some graphical content (even text well formatted), 
> save it to a file, locate and open the file in my program, 
> I'd like to go the short way and capturing the rectangle 
> directly from the screen.
> I tried copy to memory from screen snapshot, but this in 
> smart programs (LbO) works fine, myself in Gambas was not 
> able to replicate the results, using the "clipboard" object.
> I don't know why (I'll inquiry further as it would be an 
> acceptable path avoiding creating useless temp files on disk)
> 
> I don't know how to politely query another program for its 
> client-area window, I just need a bitmap copied
> 

Some combination of the following utilities might help with what you
you need.  The source code for grabc is particularly small and clear.
I've borrowed and modified some of the code from scrot to do some things.
But depending on what you are doing, you might get by with a shell script
piping some of the very flexible and useful commandline utilities that
are already available.

----
XWININFO(1)                 General Commands Manual                XWININFO(1)

NAME
       xwininfo - window information utility for X
----
XPROP(1)                    General Commands Manual                   XPROP(1)

NAME
       xprop - property displayer for X
----
XWD(1)                      General Commands Manual                     XWD(1)

NAME
       xwd - dump an image of an X window

----
GRABC(1)                    General Commands Manual                   GRABC(1)

NAME
       grabc - identifies an onscreen colour using a crosshair cursor.

SYNOPSIS
----
XDOTOOL(1)                                                          XDOTOOL(1)

NAME
       xdotool - command-line X11 automation tool

---
scrot(1)                    General Commands Manual                   scrot(1)

NAME
       scrot - capture a screenshot using imlib2

---
XCreateImage(3)                 XLIB FUNCTIONS                 XCreateImage(3)

NAME
       XInitImage, XCreateImage, XGetPixel, XPutPixel, XSubImage, XAddPixel,
       XDestroyImage - image utilities

[toc] | [prev] | [next] | [standalone]

#57280

On 26/06/19 14:35, owl wrote:
> Soviet_Mario <SovietMario@cccp.mir> wrote:
>> On 26/06/19 10:37, F. Russell wrote:
>>> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
>>>

very kind ! I'll have a look if I don't get the native 
Gambas way to work
Tnx



-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57281

Soviet_Mario <SovietMario@cccp.mir> wrote:
> On 26/06/19 14:35, owl wrote:
>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>> On 26/06/19 10:37, F. Russell wrote:
>>>> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
>>>>
> 
> very kind ! I'll have a look if I don't get the native 
> Gambas way to work
> Tnx
> 

xdotool helps a lot with x11 automation stuff:
This will give you color for a pixel at x y:
e.g. ./pixelcolor 100 300

#!/bin/bash
(xdotool mousemove ${1} ${2}; xdotool click 1) |grabc


This will capture a rectangle x1 y1 x2 y2 to /tmp/out.png:
e.g. ./rectcapture 110 212 373 400

#!/bin/bash
(xdotool mousemove ${1} ${2}
xdotool mousedown 1;
xdotool mousemove ${3} ${4}
xdotool mouseup 1) |scrot -s /tmp/out.png
 

[toc] | [prev] | [next] | [standalone]

#57284

On 26/06/19 16:00, owl wrote:
> Soviet_Mario <SovietMario@cccp.mir> wrote:
>> On 26/06/19 14:35, owl wrote:
>>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>>> On 26/06/19 10:37, F. Russell wrote:
>>>>> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
>>>>>
>>
>> very kind ! I'll have a look if I don't get the native
>> Gambas way to work
>> Tnx
>>
> 
> xdotool helps a lot with x11 automation stuff:
> This will give you color for a pixel at x y:
> e.g. ./pixelcolor 100 300
> 
> #!/bin/bash
> (xdotool mousemove ${1} ${2}; xdotool click 1) |grabc
> 
> 
> This will capture a rectangle x1 y1 x2 y2 to /tmp/out.png:
> e.g. ./rectcapture 110 212 373 400
> 
> #!/bin/bash
> (xdotool mousemove ${1} ${2}
> xdotool mousedown 1;
> xdotool mousemove ${3} ${4}
> xdotool mouseup 1) |scrot -s /tmp/out.png
>   
> 

I would prefer to avoid both "shelling" and inter-processes 
switching if not strictly inevitable and/or if done rarely 
at big chunks at a time.
One thing is to just load a library once at startup and then 
call its APIs, another is using multiple times (millions of 
times) cli commands.

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57294

Soviet_Mario <SovietMario@cccp.mir> wrote:
> On 26/06/19 16:00, owl wrote:
>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>> On 26/06/19 14:35, owl wrote:
>>>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>>>> On 26/06/19 10:37, F. Russell wrote:
>>>>>> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
>>>>>>
>>>
>>> very kind ! I'll have a look if I don't get the native
>>> Gambas way to work
>>> Tnx
>>>
>> 
>> xdotool helps a lot with x11 automation stuff:
>> This will give you color for a pixel at x y:
>> e.g. ./pixelcolor 100 300
>> 
>> #!/bin/bash
>> (xdotool mousemove ${1} ${2}; xdotool click 1) |grabc
>> 
>> 
>> This will capture a rectangle x1 y1 x2 y2 to /tmp/out.png:
>> e.g. ./rectcapture 110 212 373 400
>> 
>> #!/bin/bash
>> (xdotool mousemove ${1} ${2}
>> xdotool mousedown 1;
>> xdotool mousemove ${3} ${4}
>> xdotool mouseup 1) |scrot -s /tmp/out.png
>>   
>> 
> 
> I would prefer to avoid both "shelling" and inter-processes 
> switching if not strictly inevitable and/or if done rarely 
> at big chunks at a time.
> One thing is to just load a library once at startup and then 
> call its APIs, another is using multiple times (millions of 
> times) cli commands.
> 

You said you're not doing video graphics, so why would you need to
get a rectangle millions of times?  If you're wanting to get the
pixels individually, look at the grabc source code.

https://github.com/immunant/grabc/blob/master/grabc.c

[toc] | [prev] | [next] | [standalone]

#57297

On 27/06/19 01:05, owl wrote:
> Soviet_Mario <SovietMario@cccp.mir> wrote:
>> On 26/06/19 16:00, owl wrote:
>>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>>> On 26/06/19 14:35, owl wrote:
>>>>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>>>>> On 26/06/19 10:37, F. Russell wrote:
>>>>>>> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
>>>>>>>
>>>>
>>>> very kind ! I'll have a look if I don't get the native
>>>> Gambas way to work
>>>> Tnx
>>>>
>>>
>>> xdotool helps a lot with x11 automation stuff:
>>> This will give you color for a pixel at x y:
>>> e.g. ./pixelcolor 100 300
>>>
>>> #!/bin/bash
>>> (xdotool mousemove ${1} ${2}; xdotool click 1) |grabc
>>>
>>>
>>> This will capture a rectangle x1 y1 x2 y2 to /tmp/out.png:
>>> e.g. ./rectcapture 110 212 373 400
>>>
>>> #!/bin/bash
>>> (xdotool mousemove ${1} ${2}
>>> xdotool mousedown 1;
>>> xdotool mousemove ${3} ${4}
>>> xdotool mouseup 1) |scrot -s /tmp/out.png
>>>    
>>>
>>
>> I would prefer to avoid both "shelling" and inter-processes
>> switching if not strictly inevitable and/or if done rarely
>> at big chunks at a time.
>> One thing is to just load a library once at startup and then
>> call its APIs, another is using multiple times (millions of
>> times) cli commands.
>>
> 
> You said you're not doing video graphics, 

well, not in the sense to make animation or mass batch 
processing, apply multiple effects or so to many pictures 
... but a reasonable speed is required.
Say I want to mask and watermark a 2000x1000 pixel, it'd be 
always 2000000 millions calls. An interprocess approach to a 
console utility is out of question.
I can't even use the high level gambas native functions on 
bitmaps, I just used them once at load and once at transfer 
of finished outcome

> so why would you need to
> get a rectangle millions of times?  If you're wanting to get the
> pixels individually, look at the grabc source code.
> 
> https://github.com/immunant/grabc/blob/master/grabc.c

Thanks .... anyway as I said elsewhere, I discovered a 
"renamed" function called Desktop.Screenshot (native to 
gambas) that is lightening and supports any rectangle of the 
current screen).

Now i'm up to finding a way to also transfer the content to 
a DrawingArea or other container. I find the approach 
unfamiliar (and have to understand the difference of 
management among "dynamic" graphics, which are implemented 
via IMAGE object, and managed internally, and "static" 
graphics, impl. via PICTURE object, and said to be 
transfered to X server internal buffers : I have confused 
ideas on this multiple layer approach and thus getting 
strange results, like output that is permanent : can be 
saved on files but do not show up anywhere, and output that 
is visible but is not redrawn when a part of the window is 
covered and re-exposed).

But I don't mean to annoy the NG with these problems, as are 
no longer general linux-related.
I had tried a wrong way to bypass "impasse" (and you all 
gave kind advices).
But I still have more general problem comprehension about 
the whole graphics model of Gambas (which replicates 
somewhat the philosophy of server X).

I didn't mean to submit general programming issues, I'm 
often OT enough ! :)

> 
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57300

Soviet_Mario <SovietMario@cccp.mir> wrote:
> On 27/06/19 01:05, owl wrote:
>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>> On 26/06/19 16:00, owl wrote:
>>>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>>>> On 26/06/19 14:35, owl wrote:
>>>>>> Soviet_Mario <SovietMario@cccp.mir> wrote:
>>>>>>> On 26/06/19 10:37, F. Russell wrote:
>>>>>>>> On Wed, 26 Jun 2019 01:13:47 +0200, Soviet_Mario wrote:
>>>>>>>>
>>>>>
>>>>> very kind ! I'll have a look if I don't get the native
>>>>> Gambas way to work
>>>>> Tnx
>>>>>
>>>>
>>>> xdotool helps a lot with x11 automation stuff:
>>>> This will give you color for a pixel at x y:
>>>> e.g. ./pixelcolor 100 300
>>>>
>>>> #!/bin/bash
>>>> (xdotool mousemove ${1} ${2}; xdotool click 1) |grabc
>>>>
>>>>
>>>> This will capture a rectangle x1 y1 x2 y2 to /tmp/out.png:
>>>> e.g. ./rectcapture 110 212 373 400
>>>>
>>>> #!/bin/bash
>>>> (xdotool mousemove ${1} ${2}
>>>> xdotool mousedown 1;
>>>> xdotool mousemove ${3} ${4}
>>>> xdotool mouseup 1) |scrot -s /tmp/out.png
>>>>    
>>>>
>>>
>>> I would prefer to avoid both "shelling" and inter-processes
>>> switching if not strictly inevitable and/or if done rarely
>>> at big chunks at a time.
>>> One thing is to just load a library once at startup and then
>>> call its APIs, another is using multiple times (millions of
>>> times) cli commands.
>>>
>> 
>> You said you're not doing video graphics, 
> 
> well, not in the sense to make animation or mass batch 
> processing, apply multiple effects or so to many pictures 
> ... but a reasonable speed is required.
> Say I want to mask and watermark a 2000x1000 pixel, it'd be 
> always 2000000 millions calls. An interprocess approach to a 
> console utility is out of question.
> I can't even use the high level gambas native functions on 
> bitmaps, I just used them once at load and once at transfer 
> of finished outcome
> 
>> so why would you need to
>> get a rectangle millions of times?  If you're wanting to get the
>> pixels individually, look at the grabc source code.
>> 
>> https://github.com/immunant/grabc/blob/master/grabc.c
> 
> Thanks .... anyway as I said elsewhere, I discovered a 
> "renamed" function called Desktop.Screenshot (native to 
> gambas) that is lightening and supports any rectangle of the 
> current screen).
> 
> Now i'm up to finding a way to also transfer the content to 
> a DrawingArea or other container. I find the approach 
> unfamiliar (and have to understand the difference of 
> management among "dynamic" graphics, which are implemented 
> via IMAGE object, and managed internally, and "static" 
> graphics, impl. via PICTURE object, and said to be 
> transfered to X server internal buffers : I have confused 
> ideas on this multiple layer approach and thus getting 
> strange results, like output that is permanent : can be 
> saved on files but do not show up anywhere, and output that 
> is visible but is not redrawn when a part of the window is 
> covered and re-exposed).
> 
> But I don't mean to annoy the NG with these problems, as are 
> no longer general linux-related.
> I had tried a wrong way to bypass "impasse" (and you all 
> gave kind advices).
> But I still have more general problem comprehension about 
> the whole graphics model of Gambas (which replicates 
> somewhat the philosophy of server X).
> 
> I didn't mean to submit general programming issues, I'm 
> often OT enough ! :)
> 

You might also consider looking into the perl Image::Imlib2
interface.  Reading all pixels from a screenshot of my desktop
(1600x900) took about 2.6 seconds:

anon@lowtide:~/code/imlib2$ time ./doit >data

real    0m2.580s
user    0m2.532s
sys     0m0.044s
anon@lowtide:~/code/imlib2$ wc -l data
1440000 data
anon@lowtide:~/code/imlib2$ head data
x,y: 0,0   r: 223 g: 111 b: 0 a: 255
x,y: 0,1   r: 192 g: 95 b: 0 a: 255
x,y: 0,2   r: 192 g: 95 b: 0 a: 255
x,y: 0,3   r: 192 g: 95 b: 0 a: 255
x,y: 0,4   r: 192 g: 95 b: 1 a: 255
x,y: 0,5   r: 192 g: 95 b: 1 a: 255
x,y: 0,6   r: 192 g: 95 b: 0 a: 255
x,y: 0,7   r: 192 g: 95 b: 0 a: 255
x,y: 0,8   r: 192 g: 95 b: 0 a: 255
x,y: 0,9   r: 192 g: 95 b: 0 a: 255
anon@lowtide:~/code/imlib2$ tail data
x,y: 1599,890   r: 157 g: 152 b: 149 a: 255
x,y: 1599,891   r: 156 g: 151 b: 148 a: 255
x,y: 1599,892   r: 156 g: 151 b: 147 a: 255
x,y: 1599,893   r: 155 g: 150 b: 146 a: 255
x,y: 1599,894   r: 156 g: 151 b: 148 a: 255
x,y: 1599,895   r: 155 g: 150 b: 147 a: 255
x,y: 1599,896   r: 156 g: 148 b: 146 a: 255
x,y: 1599,897   r: 157 g: 149 b: 147 a: 255
x,y: 1599,898   r: 157 g: 149 b: 147 a: 255
x,y: 1599,899   r: 156 g: 148 b: 146 a: 255
anon@lowtide:~/code/imlib2$ 

https://manpages.debian.org/stretch/libimage-imlib2-perl/Image::Imlib2.3pm.en.html

[toc] | [prev] | [next] | [standalone]

#57266

On 2019-06-25, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
>
> It might be one of the lowest level "API" of Xwindows or 
> other window manager.
>
> Can anybody tell me which Libraries to rely on and some 
> synthax to invoke those methods in user code ?

You could look at the source for xosd.  or ico (xbase-clients)
x11perf too.

even zgv if you want to play with frameuffer instead of X.

> Maybe I do not even understand the possible risks, as in 
> this topic I still think in term of aged windows versions 
> (there I had to ask for SCREEN handle, then declare the API, 
> invoke API, and resident apis, no need to load anything 
> else, and understand the data type in/out and the _CDECL 
> declspec for ordering of parameters and stack cleanup C-like)

sdl might be worth a look, 

> now Linux is native in C, so I won't have problems in 
> understanding the exchange requirements .... but I 
> completely ignore for example if I would have the RIGHTS 
> (privilege) to invoke function from loaded external 
> libraries and services ... particularly when writing the 
> screen is concerned I'd could possibly mess up other 
> windows, even if temporarily).

Yeah permissions, you can send notifications to the desktop
notifiction channel somehow, but to draw on the screen you need
permissions, if you're root you can grab them from the environment of
the active session.

-- 
  When I tried casting out nines I made a hash of it.

[toc] | [prev] | [next] | [standalone]

#57268

On 25/06/19 17:53, Soviet_Mario wrote:
> 

addendum ...

In the "A beginners guide to Gambas" I found an example on 
pag 288 that I had not been able to replicate, using a
Desktop.Grab () method  as this seemed "discontinued" (the 
guide is a 2005 document and Gambas was at earlier versions)

Well ... I feel rather dumb (or numb ?), oh, "stupid" ... 
the method maybe was just RENAMED. Exploring the object with 
"intellisense" (or whatever the name is used in Linux for 
context aware inspection), I discovered a
"Screenshot (XLeft, Ytop, Width, Height)" method returning a 
readonly Picture object.

Now I'm gonna test it. If it works, maybe the need to act on 
physical screen directly disappears, and I would be glad to 
manage to do all the work INSIDE gambas itself.

I had headaches at the very thought of DEBUGGING a piece of 
code calling external libraries with the internal debugger, 
which is fast and handy but not exactly GDB !

ciao e grazie
(cheers and thanks for help)


> It might be one of the lowest level "API" of Xwindows or 
> other window manager.
> 
> Can anybody tell me which Libraries to rely on and some 
> synthax to invoke those methods in user code ?
> 
> I suspect Xwindows code source is simply TOO HUGE for me to 
> sieve it and just get out this couple of lowest level 
> functions (and eventual dependencies).
> 
> Maybe I do not even understand the possible risks, as in 
> this topic I still think in term of aged windows versions 
> (there I had to ask for SCREEN handle, then declare the API, 
> invoke API, and resident apis, no need to load anything 
> else, and understand the data type in/out and the _CDECL 
> declspec for ordering of parameters and stack cleanup C-like)
> 
> now Linux is native in C, so I won't have problems in 
> understanding the exchange requirements .... but I 
> completely ignore for example if I would have the RIGHTS 
> (privilege) to invoke function from loaded external 
> libraries and services ... particularly when writing the 
> screen is concerned I'd could possibly mess up other 
> windows, even if temporarily).
> 
> Some reading for suggestion ?
> 
> NOTICE : I do not need a complete program to pickup colors 
> and draw, as it would be amazingly slow. I need to directly 
> call lowest level functions just in use of the graphical 
> system running (which I suppose to be very fast)
> 
> TY
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | alt.os.linux

csiph-web