On Thu, 2002-09-05 at 23:48, Sebastien Metrot wrote:
Commit from meeloo
2002/09/05 14:48:16
________________________________________________________________________
changed the assert code for win32
--
You duplicated these two macros only to add the parentheses ? C'mon,
keep this code consistent accross platforms and avoid code duplication
... Please choose only one convention (I don't care which one as long as
it's legible) :)
Received: from zerodeux.net ([62.212.104.175])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 17tCFm-00063F-00
for <[EMAIL PROTECTED]>; Sun, 22 Sep 2002 12:18:51 -0700
Received: from localhost.localdomain (zerodeux.home [192.168.1.3])
by zerodeux.net (Postfix) with ESMTP id BCA65AFD4
for <[EMAIL PROTECTED]>; Sun, 22 Sep 2002 21:18:49 +0200 (CEST)
From: Vincent Caron <[EMAIL PROTECTED]>
To: NGL devel ML <[EMAIL PROTECTED]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8
Message-Id: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Subject: [NGL-devel] Discussion on nglKernelBase
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Sun Sep 22 12:19:13 2002
X-Original-Date: 22 Sep 2002 21:18:42 +0200
1. The Application/ApplicationBase separation (aka NOGFX). Since
application instanciation is more modular, we could achieve a nice goal
: remove the _NOGFX_ macro. We would of course still have the
nglApplication and nglApplicationBase, but the NOGFX code would be
implicitly the set of classes which don't have X/GL dependencies (this
is more fuzzy under Windows). This would be very nice for binary
distribution and package dependencies :
* libnglcore : contain core NGL and non-graphics service (currently our
NOGFX target)
* libngl : graphic classes (Window, Visual, VideoMode, etc)
And it goes on for other targets :
* libnglmaya : Maya specific classes (MayaKernel, MayaPlugin, etc)
* libnglvst...
Any comments about this goal ?
2. I'd like to remove GetResolution(), it's actually (better) supported
by nglVideoMode default constructor.
3. Is it possible/interesting to remove Get/SetGamma() ? It is expected
that KernelBase will provide a more generic handler to the display
device to do all those sort of things (GetResolution, GetGamma, etc),
and that these methods could move further away. For instance what about
nglWindow ? It would actually be more clever to assigna gamma from a
nglWindow, in order that its destruction automatically restores OS
defaults in all cases (or switches automatically on focus from one
window to another).
4. GetConsole() : let's keep it for now, but here's a proposition.
* let's add a SetConsole() to let the user control the application
console, since OUT() is handy and relies on it
* let's consider that the application console is init'ed to the default
system console (as done today)
* We might provide any number of system consoles (remove the singleton
limit), using 'virtual consoles' in one physical console (a la Linux) :
there's one display (one xterm, on win32 custom console), but we provide
facility to switch between virtual consoles (tabs, Alt+Fx, etc). Thus
there is still only one physical console per kernel, but virtual
consoles are distributed among loaded app/plugins.
5. Acquire/Release() : sounds like we are locking a ressource. I'd
prefer something like IncRef()/DecRef(). Also, is there a good reason
why it's not implemented right in nglKernelBase ?
6. Linux: I need one more entry for Idle, but I don't need all the
Add/Del methods. I actually only need :
bool AddEvent(nglEvent*);
bool DelEvent(nglEvent*);
And for the nogfx target I need to keep depencies in ascendent order,
can't talk about nglWindow here ! :)
7. Shouldn't all methods be 'protected' ?
Received: from logic.phpwebhosting.com ([66.33.1.213])
by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 17tFxn-0001aN-00
for <[EMAIL PROTECTED]>; Sun, 22 Sep 2002 16:16:31 -0700
Received: (qmail 28160 invoked by uid 508); 22 Sep 2002 23:16:21 -0000
Received: from unknown (HELO wraith) (212.195.201.185)
by logic.phpwebhosting.com with SMTP; 22 Sep 2002 23:16:21 -0000
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: [NGL-devel] Discussion on nglKernelBase
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[EMAIL PROTECTED]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Sun Sep 22 16:17:02 2002
X-Original-Date: Mon, 23 Sep 2002 01:13:12 +0200
>
> 1. The Application/ApplicationBase separation (aka NOGFX). Since
> application instanciation is more modular, we could achieve a nice goal
> : remove the _NOGFX_ macro. We would of course still have the
> nglApplication and nglApplicationBase, but the NOGFX code would be
> implicitly the set of classes which don't have X/GL dependencies (this
> is more fuzzy under Windows). This would be very nice for binary
> distribution and package dependencies :
>
> * libnglcore : contain core NGL and non-graphics service (currently our
> NOGFX target)
> * libngl : graphic classes (Window, Visual, VideoMode, etc)
>
> And it goes on for other targets :
> * libnglmaya : Maya specific classes (MayaKernel, MayaPlugin, etc)
> * libnglvst...
>
> Any comments about this goal ?
>
Great !
As far as this participates of a greater goal : globally reduce dependencies
between modules and not tying what is not related just for convenience
(telling this beacause of the Window/Gamma bindings proposed below).
>
> 2. I'd like to remove GetResolution(), it's actually (better) supported
> by nglVideoMode default constructor.
>
> 3. Is it possible/interesting to remove Get/SetGamma() ? It is expected
> that KernelBase will provide a more generic handler to the display
> device to do all those sort of things (GetResolution, GetGamma, etc),
> and that these methods could move further away. For instance what about
> nglWindow ? It would actually be more clever to assigna gamma from a
> nglWindow, in order that its destruction automatically restores OS
> defaults in all cases (or switches automatically on focus from one
> window to another).
>
2/3 are same stuff.. the display device is indeed a good thing to have
handy, but windows would be CLIENT of that module, not recipient...
(if really needed.. but I tried to figure the algo and it is not trivial)
on create
- save current settings (notepad patten)
- make desired settings ..
on focus
- make desired settings ..
ok.. but what about loosing focus or destroy ... how to avoid redundant
display switching (it can take about 5 seconds for a crt to stabilize..)
lots of guessing is needed here...
if you REALLY want two windows to have different gamma (AFAIK it's a global
colorimetric parameter you change a couple of times in a screen life-time if
ever) but this is also true for resolution switching a display device
manager would pile all windows specific settings in a stack and would be
able to know what is the right one to put on when informed of a
focus/z-order change, otherwise ??
Can't say mutch for the rest.. I didn't checked new version yet...(going to
get it right now :)
Lo.
Received: from camus.noos.net ([212.198.2.70] helo=smtp.noos.fr)
by usw-sf-list1.sourceforge.net with esmtp
(Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))
id 17tRFU-0001bh-00
for <[EMAIL PROTECTED]>; Mon, 23 Sep 2002 04:19:32 -0700
Received: (qmail 75227805 invoked by uid 0); 23 Sep 2002 11:19:09 -0000
Received: from unknown (HELO mailivs.ivs.fr) ([212.198.228.212])
(envelope-sender <[EMAIL PROTECTED]>)
by 212.198.2.70 (qmail-ldap-1.03) with SMTP
for <[EMAIL PROTECTED]>; 23 Sep 2002 11:19:09 -0000
Received: from harry (harry [192.168.0.54])
by mailivs.ivs.fr (Postfix) with SMTP id 47E6323DC49
for <[EMAIL PROTECTED]>; Mon, 23 Sep 2002 13:18:09 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: "Sebastien Metrot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] Discussion on nglKernelBase
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Mon Sep 23 04:20:02 2002
X-Original-Date: Mon, 23 Sep 2002 13:18:28 +0200
----- Original Message -----
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: "NGL devel ML" <[EMAIL PROTECTED]>
Sent: Sunday, September 22, 2002 9:18 PM
Subject: [NGL-devel] Discussion on nglKernelBase
> 1. The Application/ApplicationBase separation (aka NOGFX). Since
> application instanciation is more modular, we could achieve a nice goal
> : remove the _NOGFX_ macro. We would of course still have the
> nglApplication and nglApplicationBase, but the NOGFX code would be
> implicitly the set of classes which don't have X/GL dependencies (this
> is more fuzzy under Windows). This would be very nice for binary
> distribution and package dependencies :
>
> * libnglcore : contain core NGL and non-graphics service (currently our
> NOGFX target)
> * libngl : graphic classes (Window, Visual, VideoMode, etc)
>
> And it goes on for other targets :
> * libnglmaya : Maya specific classes (MayaKernel, MayaPlugin, etc)
> * libnglvst...
>
> Any comments about this goal ?
>
I agree about the goal which is to permit using nglcore (files, strings,
etc...) in a non ngl application or even a minimalistic application (->
nogfx). I'm not sure about dividing the libs. I yet have to see any
advantage to this and my experience of hacking away the nglKernelBase tells
me that having a nice and definitive line in between graphical and non
graphical services is very desirable but far from an easy goal.
>
>
> 2. I'd like to remove GetResolution(), it's actually (better) supported
> by nglVideoMode default constructor.
>
>
I agree.
>
> 3. Is it possible/interesting to remove Get/SetGamma() ? It is expected
> that KernelBase will provide a more generic handler to the display
> device to do all those sort of things (GetResolution, GetGamma, etc),
> and that these methods could move further away. For instance what about
> nglWindow ? It would actually be more clever to assigna gamma from a
> nglWindow, in order that its destruction automatically restores OS
> defaults in all cases (or switches automatically on focus from one
> window to another).
>
>
I think the gamma settings should be global as I haven't seen an application
modifying the gamma settings when it's not fullscreen. I don't much care
about gamma correction at the moment anyway ;). I suppose we will have to
think about multimonitor support one day, then why not having gamma be a
property of nglVideoMode?
>
> 4. GetConsole() : let's keep it for now, but here's a proposition.
>
> * let's add a SetConsole() to let the user control the application
> console, since OUT() is handy and relies on it
>
> * let's consider that the application console is init'ed to the default
> system console (as done today)
>
> * We might provide any number of system consoles (remove the singleton
> limit), using 'virtual consoles' in one physical console (a la Linux) :
> there's one display (one xterm, on win32 custom console), but we provide
> facility to switch between virtual consoles (tabs, Alt+Fx, etc). Thus
> there is still only one physical console per kernel, but virtual
> consoles are distributed among loaded app/plugins.
>
>
SetConsole can be nice but it can also be dangerous when a loaded dll sets
its console and gets unloaded. I think a first step about the console would
be to make its interface mostly pure virtual.
>
> 5. Acquire/Release() : sounds like we are locking a ressource. I'd
> prefer something like IncRef()/DecRef(). Also, is there a good reason
> why it's not implemented right in nglKernelBase ?
>
Well, we ARE locking a resource :-).
No good reason but it must stay virtual (just in case of...).
>
>
> 6. Linux: I need one more entry for Idle, but I don't need all the
> Add/Del methods. I actually only need :
>
> bool AddEvent(nglEvent*);
> bool DelEvent(nglEvent*);
>
> And for the nogfx target I need to keep depencies in ascendent order,
> can't talk about nglWindow here ! :)
>
>
In fact I don't need AddWindow or AddTimer or anything under Win32 and
MacOSX so I propose that these event management methods be defined only when
a platform needs them:
#ifdef __UNIX__
bool AddEvent(nglEvent*);
bool DelEvent(nglEvent*);
#endif
>
> 7. Shouldn't all methods be 'protected' ?
>
Why all methods?? Most methods are transfered from the original
nglApplicationBase, I think these methods should be accessible from anybody,
no?
MeeLoo
Received: from zerodeux.net ([62.212.104.175])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 17tcsT-0000nG-00
for <[EMAIL PROTECTED]>; Mon, 23 Sep 2002 16:44:34 -0700
Received: from localhost.localdomain (zerodeux.home [192.168.1.3])
by zerodeux.net (Postfix) with ESMTP id 4F524B2DD
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 01:44:34 +0200 (CEST)
From: Vincent Caron <[EMAIL PROTECTED]>
To: NGL devel ML <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8
Message-Id: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Subject: [NGL-devel] Re: [ngl-cvs] Trying to cleanup some mess
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Mon Sep 23 16:45:01 2002
X-Original-Date: 24 Sep 2002 01:44:27 +0200
I don't know if it compiles, the current code is utterly broken. I'm
disappointed by the Maya and VST kludges that still make their way in
various places, when the first goal was actually to remove this kind of
problem. And the general mess : please try to commit at least correct
headers (no declaration duplicates, properly closed Doxygen tags, no
excessive 'friends', nice indentation, DOCUMENTATION). Thanks...
Now let's make some things clear. The kernel holds what's global to a
process, and thus covers the lifespan of a process. In a process we have
:
* 1 kernel in any time, any event
* 0 or 1 nglApplication/nglApplicationBase
* 0..n plugins
Since for some architectures (Unix mainly), the event loop is unique to
a process, it goes right in the kernel. The application log must also be
unique to a process, because it is a 'library wide' object : NGL methods
expect it's always there. Some other global services can fit in, when
they make sense :
* I removed gamma since it was unimplemented, we'll see later
(it's not that global, cf. multi-monitor support and per-context
gamma)
* The clipboard seems to fit in the kernel
In the next commit I'll move the log and logdomain stuff to
nglKernelBase where it belongs.
Received: from kraid.nerim.net ([62.4.16.95])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 17tmDe-000254-00
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 02:43:02 -0700
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by kraid.nerim.net (Postfix) with ESMTP id 978A040F61
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 11:34:43 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [NGL-devel] Re: [ngl-cvs] adapted cleanup code so that it compiles and
runs (at
least on the mac ;P)...
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Tue Sep 24 02:44:01 2002
X-Original-Date: Tue, 24 Sep 2002 11:43:19 +0200
Meelo, you removed nglKernelBase_shr.cpp from src/core/Makefile, was
that done on purpose ?
Received: from zola.noos.net ([212.198.2.76] helo=smtp.noos.fr)
by usw-sf-list1.sourceforge.net with esmtp
(Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))
id 17tn06-0000Iq-00
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 03:33:06 -0700
Received: (qmail 3438836 invoked by uid 0); 24 Sep 2002 10:25:23 -0000
Received: from unknown (HELO mailivs.ivs.fr) ([212.198.228.212])
(envelope-sender <[EMAIL PROTECTED]>)
by 212.198.2.76 (qmail-ldap-1.03) with SMTP
for <[EMAIL PROTECTED]>; 24 Sep 2002 10:25:23 -0000
Received: from harry (harry [192.168.0.54])
by mailivs.ivs.fr (Postfix) with SMTP id B905C23DC49
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 12:24:39 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: "Sebastien Metrot" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] Re: [ngl-cvs] adapted cleanup code so that it compiles
and runs (at least on the mac ;P)...
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Tue Sep 24 03:34:02 2002
X-Original-Date: Tue, 24 Sep 2002 12:11:27 +0200
It was allready in src/core/Makefile :-).
I had multiple defined ids under carbon :-).
MeeLoo
----- Original Message -----
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 24, 2002 11:43 AM
Subject: [NGL-devel] Re: [ngl-cvs] adapted cleanup code so that it compiles
and runs (at least on the mac ;P)...
> Meelo, you removed nglKernelBase_shr.cpp from src/core/Makefile, was
> that done on purpose ?
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> NGL-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/ngl-devel
>
Received: from mallaury.noc.nerim.net ([62.4.17.82])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 17tsGP-0006X1-00
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 09:10:17 -0700
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by mallaury.noc.nerim.net (Postfix) with ESMTP id 18C3269A2B
for <[EMAIL PROTECTED]>; Mon, 23 Sep 2002 11:31:18 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] Discussion on nglKernelBase
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Tue Sep 24 09:11:02 2002
X-Original-Date: Mon, 23 Sep 2002 11:31:39 +0200
Lorenzo Pastrana wrote:
>>2. I'd like to remove GetResolution(), it's actually (better) supported
>>by nglVideoMode default constructor.
>>
>>3. Is it possible/interesting to remove Get/SetGamma() ?
>
> 2/3 are same stuff.. the display device is indeed a good thing to have
> handy, but windows would be CLIENT of that module, not recipient...
[...]
> ok.. but what about loosing focus or destroy ... how to avoid redundant
> display switching (it can take about 5 seconds for a crt to stabilize..)
> lots of guessing is needed here...
You're making two mistakes IMHO :
- nglVideoMode is not about _setting_ a video mode (this is nglWindow's
job), but enumerating the available modes. Hence changing the video mode
only occurs for fullscreen windows, and you only loose explicitely the
focus on these ones (Alt+Tab)
- setting screen gamma is a costless and instantaneous operation (this
is a LUT in the video DAC). What's more, we should expect to have
per-context gamma settings in future chipsets, the ATI Radeon 9700
already has nice features such as gamma-corrected blending :
"On the image quality front, the Radeon 9700 employs a simple but
effective new twist: gamma correct blending. When the chip blends
sampled color values together, it applies a gamma curve. Gamma
correction at various points in the pixel pipeline is encouraged in the
DirectX 9 spec. Because graphics chips must operate in a gamma
colorspace, this technique only makes sense."
http://tech-report.com/reviews/2002q3/radeon-9700pro/index.x?pg=13
Received: from logic.phpwebhosting.com ([66.33.1.213])
by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 17twxn-0006xw-00
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 14:11:23 -0700
Received: (qmail 18015 invoked by uid 508); 24 Sep 2002 21:10:53 -0000
Received: from unknown (HELO wraith) (212.195.69.198)
by logic.phpwebhosting.com with SMTP; 24 Sep 2002 21:10:53 -0000
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: [NGL-devel] Discussion on nglKernelBase
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <[EMAIL PROTECTED]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Tue Sep 24 14:12:03 2002
X-Original-Date: Tue, 24 Sep 2002 23:08:02 +0200
Hi vincent,
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Vincent Caron>
> You're making two mistakes IMHO :
>
> - nglVideoMode is not about _setting_ a video mode (this is nglWindow's
> job), but enumerating the available modes. Hence changing the video mode
> only occurs for fullscreen windows, and you only loose explicitely the
> focus on these ones (Alt+Tab)
Well even if nglVideoMode was mentionned, my concern was about (not)managing
video settings directly into nglWindow. These considerations comes from
experience I had on Sphere times ago, trying to solve some tricky issues
with multiple windows/screens setups...
What is to be avoided (IMHO) is the
OnDie/OnLooseFocus->RestorePreviousState kind of management, since you can't
know from nglWindow point of view if the previous state is pertinent.
I was speculating on some nglVideoDevice (aka screen) holding a
nglVideoState (window_handle,Z,resolution,colordepth,gamma) table.
nglVideoDevice would be indeed triggered for change by nglWindow's events
(focus/life). The motivation for sutch a module is to have a place where all
pending settings (I mean actual per-windows settings) are stored in order to
reduce changes to the actual delta (especially when changing resolution),
this allows an overall knowledge of z-order & relatives settings, that would
be uggly to manage without sutch a sructure...
I'd better think of something like :
OnDie/OnLooseFocus->TellVideoDevice witch can figure out what to do...
> - setting screen gamma is a costless and instantaneous operation (this
mmmh, I think I know that...
But at an application level (even per-context) it is still a global
colorimetric correction, even if HW implementation provides correction at
various points in the pixel pipeline. But anyway as you can read, my point
was not really about the nature of Gamma.
Cheers.
Lo.
.
Received: from zerodeux.net ([62.212.104.175])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 17tyCa-00014M-00
for <[EMAIL PROTECTED]>; Tue, 24 Sep 2002 15:30:44 -0700
Received: from localhost.localdomain (zerodeux.home [192.168.1.3])
by zerodeux.net (Postfix) with ESMTP id 9EAD9B44A
for <[EMAIL PROTECTED]>; Wed, 25 Sep 2002 00:30:43 +0200 (CEST)
Subject: RE: [NGL-devel] Discussion on nglKernelBase
From: Vincent Caron <[EMAIL PROTECTED]>
To: NGL devel ML <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8
Message-Id: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Tue Sep 24 15:31:02 2002
X-Original-Date: 25 Sep 2002 00:30:37 +0200
On Tue, 2002-09-24 at 23:08, Lorenzo Pastrana wrote:
>
> I was speculating on some nglVideoDevice (aka screen) holding a
> nglVideoState (window_handle,Z,resolution,colordepth,gamma) table.
> nglVideoDevice would be indeed triggered for change by nglWindow's events
> (focus/life). The motivation for sutch a module is to have a place where all
> pending settings (I mean actual per-windows settings) are stored in order to
> reduce changes to the actual delta (especially when changing resolution),
> this allows an overall knowledge of z-order & relatives settings, that would
> be uggly to manage without sutch a sructure...
The windowing system already holds this kind of info for you, this is
actually its job. The 'per-window gamma' was only meant to be a
'reasonnable kludge'. The only worst case you could handle is switching
from two fullscreen windows (without passing through the desktop's
resolution mode). We do however have the proper infrastructure to do
things right (TM) :
- nglVideoMode : currently enumerates the available video modes of the
main screen. This should be enhanced with a nglScreen class (VideoDevice
will be used for capture device) to enumerate screens and do proper
nglVideoMode::Enum(nglScreen = physical device). BTW, nglVideoMode might
be renamed as nglScreenMode (?)
- nglVisual : currently enumerates the available context modes of the GL
driver attached to the main screen. nglVisual accepts a 'fullscreen'
flag, it should rather take a nglVideoMode instead, to know which
screen/GL driver to deal with.
- in nglWindow : this the only moment where you know if you can create a
context with a given {nglVisual, nglVideoMode} couple. Reasons why it
can fail and we could not tell it before trying to create the context :
* GL driver was boasting about its capabilities, it actually can't
handle the visual
* not enough memory. Even if the nglVideoMode was a fullscreen one (ie.
resolution is known, thus buffers footprint could be estimated to fit or
not VRAM), glX/WGL gives no way to foresee this situation
* windowed mode, crossing two screens where each screen is managed by a
different GL driver, one of them doesn't having the necessary
capabilities
* meteorology and murphy
As for 'context switching' optimization, we already have all
informations (wether in OS space or in NGL classes) to do what's best. I
don't say we already do what's best :)
Received: from logic.phpwebhosting.com ([66.33.1.213])
by usw-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 17u8Jd-0006mr-00
for <[EMAIL PROTECTED]>; Wed, 25 Sep 2002 02:18:41 -0700
Received: (qmail 845 invoked by uid 508); 25 Sep 2002 09:18:11 -0000
Received: from unknown (HELO wraith) (212.194.54.69)
by logic.phpwebhosting.com with SMTP; 25 Sep 2002 09:18:11 -0000
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: RE: [NGL-devel] Discussion on nglKernelBase
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[EMAIL PROTECTED]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Wed Sep 25 02:19:02 2002
X-Original-Date: Wed, 25 Sep 2002 11:15:24 +0200
>
> As for 'context switching' optimization, we already have all
> informations (wether in OS space or in NGL classes) to do what's best. I
> don't say we already do what's best :)
>
yep!yep.. okok ;)
Was just a comment about that particular moove you were talking about...
BTW :
Google translation service and myself can't tell what a kludge is ...
Lo.
.
Received: from kraid.nerim.net ([62.4.16.95])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 17u8MO-00073H-00
for <[EMAIL PROTECTED]>; Wed, 25 Sep 2002 02:21:32 -0700
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by kraid.nerim.net (Postfix) with ESMTP id F26C540FCF
for <[EMAIL PROTECTED]>; Wed, 25 Sep 2002 11:13:12 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [NGL-devel] Re: [ngl-cvs] fixing win32 compilation after an attack
from unix
people ;-D
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Wed Sep 25 02:22:02 2002
X-Original-Date: Wed, 25 Sep 2002 11:21:31 +0200
Sebastien Metrot wrote:
> *Commit from /meeloo/* 2002/09/24 18:12:12
>
> ------------------------------------------------------------------------
>
> | fixing win32 compilation after an attack from unix people ;-D
I'd like to instantiate the console as soon as possible (instead of
first call to GetConsole()) for at least two reasons :
* don't miss startup log lines (the console is the default medium for
the log)
* this console is expected to be the 'unique physical console',
accepting further virtual consoles by means of other nglConsole instances
I agree that the 'new nglConsole' and 'new Log' should be moved out from
nglKernelBase constructor, in order to be called after some platform
specific init. This will be done tonight I guess.
Received: from kraid.nerim.net ([62.4.16.95])
by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 17u8Qk-0007V8-00
for <[EMAIL PROTECTED]>; Wed, 25 Sep 2002 02:26:02 -0700
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by kraid.nerim.net (Postfix) with ESMTP id 21F8B40E2C
for <[EMAIL PROTECTED]>; Wed, 25 Sep 2002 11:17:44 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1)
Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] Discussion on nglKernelBase
References: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=ngl-devel>
Date: Wed Sep 25 02:27:02 2002
X-Original-Date: Wed, 25 Sep 2002 11:26:02 +0200
Lorenzo Pastrana wrote:
> Google translation service and myself can't tell what a kludge is ...
This is a 'hack', but somewhat worse on the scale of hacks :)
The full monthy : http://www.tuxedo.org/~esr/jargon/html/entry/kludge.html
