• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Doodle

#1
Open Bounties / Re: Porting AbiWord
2011.05.18, 13:04:46

Hi boys,

I wouldn't like to move the flame forward, but I just can't keep it to myself.

Quote from: osw on 2011.05.18, 12:22:18
So give me one reason to vote for gradd.
The solution proposed by Demetrious - 3d accelerated driver for os/2 - may give us some cool possibilities -  3d api, compositing manager, alpha compostiting (you know - even smartphones have it now) - so new look and performance to os/2.
So, again - give me one reason to bother with gradd? Nostalgia? Dos sessions? Win-OS/2 sessions? (rotfl)

Please note that I'm following GL/2 with great hopes, and I'm absolutely not against its chosen directions, I just simply don't understand why would one want to throw out GRADD.

GRADD is a general Graphics Adapter Device Driver architecture, which was designed with an exceptional extensibility in mind, meaning that it was (it is) prepared for every existing and future feature of a graphics card. Even more, one can create filters to modify how an old GRADD device driver works.
Adding 3D capabilities to an existing OS/2 system which uses a GRADD-based video driver would just mean one more GRADD module/driver to be installed. So, a 3D driver would nicely fit into the modular GRADD architecture.

The bigger problem I see is the fact that the OS/2 Presentation Manager and all the graphical OS/2 applications use the GPI API to draw something on the screen. If an application asks for a circle to be drawn, it has to be boiled down to the graphics card somehow, right?
Now, when IBM decided to throw out the old video driver architecture, and introduced the much more clear GRADD architecture instead, they have written the "transition layer" which connects the GPI API with the GRADD drivers (gre2vman.dll, anyone?), so the old OS/2 PM applications did not have to be changed, they ran without modifications on the new video driver architecture.

I'd just like to point out that, in case the whole GRADD architecture is going to be thrown out, somebody will have to write a new transition layer, which will be quite a huge work, including a lot of gray and undocumented areas of the OS/2 PM API. Combining this with my non-understanding why GRADD does not fit for GL/2, I just don't see why was this path chosen.

Again, I'm absolutely not against GL/2's current plans and directional decisions (anyway, who I am to be?), these are just my thoughts on the case.

And please let me have one more sentence: as I understood Rudi's posts, I think he was also quite interested in GL/2, and tried to understand some of the decisions (having similar problems like me) to be able to help... too bad that some misunderstanding or miscommunication or whatever came into the picture...

Doodle
#2
Internet / Re: Firefox 3.x Font Issue?
2008.08.14, 12:27:24
Quote from: RobertM on 2008.08.13, 21:23:35

But that brings up questions... what version of Cairo should be installed on the system? Or is the required code built into the browser?


Firefox has its own Cairo library compiled into the Firefox executable.
So, it doesn't matter which Cairo runtime DLLs you have installed (it doesn't matter if you have the Cairo runtime DLLs installed at all), Firefox uses its own.

The Cairo runtime DLLs are (currently) only used by some DSSaver modules and WPSWizard.

Doodle
#3
FYI:

I took a quick look at the VICE source code, and found the problem.
I've already sent the fix to the VICE developer mailing list, and I hope that they can make a new build with that soon.

Bye,
  Doodle
#4
Quote from: cytan on 2008.07.14, 16:54:22

So, with that out of the way, I decided to set up Doodle screen saver to Analogue TV (ATV) simulator which uses DIVE like the Matrix module. It seems that ATV, like the Matrix module chews up shared memory like crazy especially after running OpenOffice 2.0 which is a real shared memory hog.

(...)

cytan

P.S. this is with CAIRO 1.6.4 and Doodle Screen saver v18


Could you please contact me directly in e-mail about this problem?
(I don't check these forums very regularly, that's why...)

It's enough if you write me how to reproduce the problem (e.g.: use a saver module in Dive mode), and what are the symptoms (this and that app shows that shared memory goes down...).

Thanks,
  Doodle
#5

Could you please try to switch to some other module instead, which can use DIVE and/or WarpOverlay?
(I'd be interested if it's related to the usage of those subsystems, or if it's really Matrix-specific.)

Btw, do you have WarpOverlay installed? Did you enable the usage of WarpOverlay in Matrix module?

Doodle
#6

Well, I'd do the following in this case:
- First, try to reproduce it.
- Then, once it's reproducible, change saver module to blank, and try it that way.
  (This way we can make sure if the problem is in the module or in the saver.)
- Then contact the author (me :) ), and ask for help. He'll most probably send you a debug version of the problematic part to see what's going wrong, and then he'll fix it, if he can. :)

Good luck!
  Doodle
#7

Frosh,

Please let me know if you stuck somewhere with the porting. Not that I'm that much up to date with FreePascal, but I think I can still help you.

Doodle
#8

Hi there,

Sorry to say that I don't have time to port them either, but please let me know if I can help you in any other ways!
I'd be interested in which manual you've read (which is not descriptive enough), so I may extend it.

Anyway, to create new screen saver modules, one has to download the sources of DSSaver (these are in the "srcbin" packages). That package has a readme.txt, which tells that you'll need the OpenWatcom C/C++ compiler and the OS/2 Developer's Toolkit to be able to compile the sources. The first one is freely downloadable, the second one is on one of the eCS CDs.

Then, there is a PDF in the package, called SSaver Programmers Guide, which describes the possibilities and the API of the screen saver system. You should read that one too, to get an idea on how the DSSaver core and its modules cooperate.

Bye,
  Doodle