flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > Process Drawing and threads...

Author
Thread Post new topic Reply to topic
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
I would like to make a request...
(or if noone else will bother to do it.. i will after i finishe a few other projects in MeOS)

Currently, the kernal does not allow a process to draw outside its window...
unless you count background stuff... but thats not what i mean.
Also, you cannot draw pixels, lines, etc unless the process HAS a window...

Bassically this prevents having threads do anything graphically usefull.
It also prevents some drawing which could be useful/interesting.

I would like to make GUI code that runs seperate threads... for things like
textboxes,menus, drag and drop controls. Threading would allow for better controll of events to such GUI objects, including mouse movements.

So perhaps the basic drawing procedures could have additions to them that would allow the programmer to draw in any process window, based on its process ID.

What does everyone think?
Wishing

_________________
446f6c7068696e
Post 03 Sep 2004, 06:20
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
Barak



Joined: 25 Jul 2003
Posts: 22
Location: Nesher, Israel
Barak
Good Idea, sounds good, I'm sorry but I don't know asm Sad
Post 03 Sep 2004, 21:16
View user's profile Send private message ICQ Number Reply with quote
Mike Hibbett



Joined: 02 Sep 2003
Posts: 88
Location: UK
Mike Hibbett
humm.. I'm not sure how you could efficiently transfer the data from one application to anothers window. You might want to discuss the design as it evolves before doing any coding.

Cheers,

Mike
Post 04 Sep 2004, 10:01
View user's profile Send private message AIM Address Reply with quote
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
there would be no data transfer at all...
One application would simply be able to spawn threads
(bassically other applications)
and they would be allowed to write outside of thier own window...
since they are threads... there is no context switch in the cpu... therefore they can access data from the parent process. Things like the window position... then all you have to do is draw 'above' the window below...
All of this stuff already exists witht he exception that threads and programs cannot draw outside thier own windows...

All that is needed is to allow process and threads to be able to draw anywhere on the screen, even if they dont have a window.
there must be some bounding procedure in the drawing routeins that could be overiden...

Wishing

_________________
446f6c7068696e
Post 07 Sep 2004, 16:11
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
Mike Hibbett



Joined: 02 Sep 2003
Posts: 88
Location: UK
Mike Hibbett
But what happens when another application draws over that 'drawing'. How do you know that the original application must redraw it? What if the drawing went over another applications window?

I haven't played with it myself, but have you tried this function?

61 = DIRECT GRAPHICS ACCESS

ebx = 1 - get resolution -> eax [x] shl 16 + [y]
ebx = 2 - get bits per pixel -> eax
ebx = 3 - get bytes per scanline -> eax

direct access with gs selector : mov [gs:0],dword 0xffffff


Mike.
Post 07 Sep 2004, 17:14
View user's profile Send private message AIM Address Reply with quote
Tolle



Joined: 21 Jan 2004
Posts: 71
Tolle
IMHO, It's much better to have one thread doing all the drawing than several pieces of code all over the place.

Another possibilty would be to use transparent windows. This way we could detect if application X is trying to write over app Y. (& pretend it -is- app Y)

If app Y is a system warning of the
"App X wants to delete all your files, is this ok? [Yes/No]" type.
It's much easier to prevent app X writing "Click yes to continue [Yes/No]" over it.
Post 08 Sep 2004, 14:04
View user's profile Send private message Visit poster's website Reply with quote
profkid13



Joined: 21 Aug 2003
Posts: 112
profkid13
Mike Hibbett wrote:
But what happens when another application draws over that 'drawing'. How do you know that the original application must redraw it? What if the drawing went over another applications window?


Mhmm, we already have this bug with the icons (if you click an icon that is half covered by an app, it will "cut" a piece out of the app Razz) so the code could get handy inhere too Razz
Post 08 Sep 2004, 16:36
View user's profile Send private message Reply with quote
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
I would think thats having a textbox be seperately threaded would be nice... since then the origonal app could continue drawing whatever while you entered in afilename etc...
To tell if the origonal application must redraw it... the origonal application simply tells the thread to redraw when it needs to redraw... and since the thread is only writing atop its parent process window... thats ok... since if one needs to be redrawn they both do anyways. I dont mean drawing outside of EVERY window like atop the desktop... but drawing only over another window, yet outside your own. Ie you can only draw 'down' the window stack one level.. or something along those lines.

I like the transparent window idea...
also about the icons... the moveable icons I made have problems like that too... they can only get the background image... and not the actual video ram... so when you move em over like the panel bar... they draw the background behind it over it.

Wishing

_________________
446f6c7068696e
Post 08 Sep 2004, 19:54
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
Wishing, how many processors / system buses do you have on your server?

MATRIX
Post 09 Sep 2004, 00:01
View user's profile Send private message Visit poster's website Reply with quote
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
Why does it matter? were not talking about atomic assembly code... threads have nothing to do with that. What server are you talking about?
I only have one CPU.
Post 10 Sep 2004, 01:05
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
Wishing wrote:
Why does it matter? were not talking about atomic assembly code... threads have nothing to do with that. What server are you talking about?
I only have one CPU.


I would think thats having a textbox be seperately threaded would be nice... since then the origonal app could continue drawing whatever while you entered in afilename etc...

i was thinking about your previous thoughts especially about that while

MATRIX
Post 10 Sep 2004, 06:08
View user's profile Send private message Visit poster's website Reply with quote
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
I honestly still dont follow you...

are you trying to say there is noo need to have threaded textboxes?

What about as you MADE that post in this forum... werent there .gif smiley animations animating AS you typed in the post textbox?? I wouldnt be surprised if those animations are seperate threads from the one the textbox is. Currently in Menuet, most of the apps must stop and wait for the contents of a textbox to be filled out. Now in some.. this doesnt matter at all... but perhaps in the future it will.

_________________
446f6c7068696e
Post 10 Sep 2004, 17:42
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
Wishing wrote:
I honestly still dont follow you...

are you trying to say there is noo need to have threaded textboxes?

What about as you MADE that post in this forum... werent there .gif smiley animations animating AS you typed in the post textbox?? I wouldnt be surprised if those animations are seperate threads from the one the textbox is. Currently in Menuet, most of the apps must stop and wait for the contents of a textbox to be filled out. Now in some.. this doesnt matter at all... but perhaps in the future it will.


well maeby noone understands me,
no problem i have already got used to it.

MATRIX
Post 10 Sep 2004, 18:25
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.