 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e602437$1@news.povray.org>,
"Ian J. Burgmyer" <the### [at] mac com> wrote:
> > but...try MegaPOV.
>
> Think that'll work? My problem sounds...eh...kind of strange. :)
>
> AFAIK the Unix version of 3.5 works fine, it's the Mac OS build that's giving
> me massive headaches.
The problems are due to the Mac-specific parts of the code, MacMegaPOV
has completely different code for this. The official version often
refuses to use all available processor time (though I haven't seen it as
bad as you describe...for me it usually only leaves 20-30% idle).
MegaPOV doesn't have this problem.
The official version also breaks a few Mac OS X UI conventions, such as
putting the working Quit item in the wrong menu (and having a
non-working Quit item in its place), MacMegaPOV is better in this
respect. It's just more useable.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff's furious key-hammering produced this:
>> Think that'll work? My problem sounds...eh...kind of strange. :)
>
> The problems are due to the Mac-specific parts of the code, MacMegaPOV
> has completely different code for this. The official version often
> refuses to use all available processor time (though I haven't seen it as
> bad as you describe...for me it usually only leaves 20-30% idle).
I *did* have iTunes playing a CD in the background (I hid it and forgot about
it, so that might have something to do with the severity of the problem). I
used top to get the resultes, btw.
> MegaPOV doesn't have this problem.
Oh, okay...I'll have to download that tomorrow, then.
I thought my problem with OS 9.2 was odd (clicking "render" doesn't seem to do
much of anything, telling it to stop freezes POV), but it looks like switching
preempitive threading on will fix that. Eh, I might just get MacMegaPOV
instead. That'll be much easier. ;)
> The official version also breaks a few Mac OS X UI conventions, such as
> putting the working Quit item in the wrong menu (and having a
> non-working Quit item in its place)
Oh yeah, isn't the working Quit item in the "File" menu rather than the
application's menu? I didn't use MacPOV much, but this confused me when I first
saw it.
--
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
> The official version also breaks a few Mac OS X UI conventions, such as
Well, you could also say Mac OS X breaks all GUI conventions intelligent
people at Apple spend decades to refine. You should not only look at the
CPU time wasting effects Mac OS X brings, but also the millions of bugs and
things it breaks. From the useless window layering to the dock. Nothing
works. Hardly better than Windos in the end. And it needs more memory than
Windos already <sigh> But of course, under the current leadership at Apple
a consistent and easy to use user interface is no longer a topic at all.
Just look at Safari's non-standard appearance...
> putting the working Quit item in the wrong menu (and having a
> non-working Quit item in its place), MacMegaPOV is better in this
> respect. It's just more useable.
Sure, except that the interface is non-standard in every other respect. The
Quit menu belongs into the file menu, period. And the stupid application
menu is just one big usability madness: Maybe you did not notice, but with
the application name being the leftmost item the whole menu moves around in
every application. Add the wrong window layering and you end up with
unpredictable menu positions. I actually saw a usability test of a Mac
application recently, and it was one of the most visible problems (users
constantly ended up in the wrong menu after accidentally activating the
wrong window and not noticing they were in a different application). So it
is clear that Apple didn't do any user testing with the Aqua menu interface
before forcing it on developers <sigh>
But of course, nobody cares about lost productivity these days in desktop
systems, only about the upfront cost of the hardware and software
combination relative to the "coolness" factor :-(
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
> The problems are due to the Mac-specific parts of the code, MacMegaPOV
> has completely different code for this. The official version often
> refuses to use all available processor time (though I haven't seen it as
> bad as you describe...for me it usually only leaves 20-30% idle).
> MegaPOV doesn't have this problem.
That is not true, you just don't know what you are talking about!
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e60b344$1@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> > The problems are due to the Mac-specific parts of the code, MacMegaPOV
> > has completely different code for this. The official version often
> > refuses to use all available processor time (though I haven't seen it as
> > bad as you describe...for me it usually only leaves 20-30% idle).
> > MegaPOV doesn't have this problem.
>
> That is not true, you just don't know what you are talking about!
It is true. The official version with GUI has the problem, the command
line version and MacMegaPOV do not. The problem is definitely not in the
core code, I don't see how you can seriously claim otherwise.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
>> That is not true, you just don't know what you are talking about!
>
> It is true. The official version with GUI has the problem, the command
> line version and MacMegaPOV do not. The problem is definitely not in the
> core code, I don't see how you can seriously claim otherwise.
It is the priority setting of the OS for GUI applications. Grap too much
and you see a beachball. Command-line versions don't have a user interface
to serve, thus their priorities are handled very differently. The only
working way around the beachball is to use MP threads *and* pure Carbon
Events. Sadly that is easier said than done because Carbon Events replace
WaitNextEvent in a manner that isn't in every respect compatible with object
oriented applications:
Due to the need of "timers" and their callback functions which can end up
being called while your object is half-destroyed. To be precise, you have
to install and remove timer callbacks in the highest derived class because
otherwise (that is in the lowest common base class that needs the timer,
i.e. a "window" base class) while being in a destructor the timer can fire
and the high-level object parts (i.e. "textwindow") are already destroyed
but the timer has not been disabled in the base class yet (because the
destructor function of "window" hasn't been called yet). This makes using
Carbon Events a bit more tricky than they should be, and that is why many
applications don't use them (the Finder doesn't fully use them as well, it
seems)...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e60b2f7$1@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Well, you could also say Mac OS X breaks all GUI conventions intelligent
> people at Apple spend decades to refine.
You could. I don't.
> You should not only look at the CPU time wasting effects Mac OS X
> brings, but also the millions of bugs and things it breaks.
My CPU is idle most of the time. *That* is wasted CPU time. And yes it
has bugs, the old Mac OS had plenty of bugs too. Considering its age, it
is doing quite well.
> From the useless window layering to the dock. Nothing
> works. Hardly better than Windos in the end. And it needs more memory than
> Windos already <sigh> But of course, under the current leadership at Apple
> a consistent and easy to use user interface is no longer a topic at all.
Everything works. I find it far better than Windows. I've got enough
memory. The current leadership gave me this, and I'm happy about it.
> Just look at Safari's non-standard appearance...
Yes, annoyingly inconsistent look, but still easy to use. I like the way
it handles bookmarks.
> Sure, except that the interface is non-standard in every other respect. The
> Quit menu belongs into the file menu, period.
No it doesn't, it goes in the application menu.
> And the stupid application menu is just one big usability madness:
> Maybe you did not notice, but with the application name being the
> leftmost item the whole menu moves around in every application.
So? It's never been a problem for me. The application menu is bold, it
makes a nice visual target to offset from. The ordering does not change,
and the movement is not much.
All this is irrelevant anyway...point is that the official Mac version
of POV-Ray does not work properly under Mac OS X. That is a simple fact,
and has nothing to do with your opinions of the Mac OS X GUI. MacMegaPOV
may have its own inconsistencies, but overall it has been much more
reliable and it actually works right, so I am going to recommend it over
the official version.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
>> Just look at Safari's non-standard appearance...
>
> Yes, annoyingly inconsistent look, but still easy to use. I like the way
> it handles bookmarks.
I like that too. And I think it wouldn't be a problem at all to switch the
window theme, just a bit hacking of resources should do. But that would not
fix several other non-standard interfaces, like the background in the
download window...
>> Sure, except that the interface is non-standard in every other respect. The
>> Quit menu belongs into the file menu, period.
>
> No it doesn't, it goes in the application menu.
There shouldn't be an application menu of the kind that currently exists.
The same goes for preferences. Remember that menus convey actions, not
concepts. Do you "application" preferences or do you "edit" preferences for
example? Sure, by concept preferences are an application property, but by
action you edit them. hence they belong into the Edit menu.
The Quit menu item is a bit more tricky. You may recall the OpenDoc days
when Apple tried to leave the concept of "application" behind (which would
have been a quantum leap had it been adopted by developers). In that design
there was no "Quit" menu item at all. Now, in Mac OS X by changing the
window layering Apple on the one hand tries to weaken the concept of
application regarding windows, but on the other hand strengthens it by
adding an additional menu for it. And _that_ is inconsistent and the root
of all the problems :-(
>> And the stupid application menu is just one big usability madness:
>> Maybe you did not notice, but with the application name being the
>> leftmost item the whole menu moves around in every application.
>
> So? It's never been a problem for me. The application menu is bold, it
> makes a nice visual target to offset from. The ordering does not change,
> and the movement is not much.
The position moves. If you tape users you will notice menu selection takes
much longer compared to Mac OS. On average, the same tasks performed in a
usability test (that didn't seek to test Mac OS vs Mac OS X usability, it
just happened that one system in one location had 9.2.1 and the other at
another location 10.2.3 installed) showed, and which was very surprising,
for tasks that they took Mac OS 9 users 33 minutes and Mac OS X users 37
minutes to complete on average (7 and 12 users respectively). That is a
"only" 12% difference, but on a full 8 hour workday is almost one hour of
lost productivity! The test involved a website used with IE (because it was
available on both systems) and viewing downloaded data in Excel and
Acrobat...
> All this is irrelevant anyway...point is that the official Mac version
> of POV-Ray does not work properly under Mac OS X.
There is only a (very specific) problem with 10.2, which, as you may recall,
was released *after* the official POV-Ray 3.5. MacMegaPOV on the other hand
was released much later...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e60dc90@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> There shouldn't be an application menu of the kind that currently exists.
> The same goes for preferences. Remember that menus convey actions, not
> concepts. Do you "application" preferences or do you "edit" preferences for
> example? Sure, by concept preferences are an application property, but by
> action you edit them. hence they belong into the Edit menu.
File. Special. Apple. Window. Web browsers often have things like
History and Bookmarks.
Menu *commands* convey actions, and even that is a general rule, with
exceptions (such as the Window menu...but you probably don't like that
either). Preferences belong in the Application menu, putting them in the
menu containing document editing commands never made sense to me.
> for tasks that they took Mac OS 9 users 33 minutes and Mac OS X users 37
> minutes to complete on average (7 and 12 users respectively). That is a
> "only" 12% difference, but on a full 8 hour workday is almost one hour of
7 OS 9 users and 12 OS X users, at completely different locations? 4
minutes difference? That study doesn't show anything about the usability
differences.
> lost productivity! The test involved a website used with IE (because it was
> available on both systems) and viewing downloaded data in Excel and
> Acrobat...
Ugh...IE under OS X is a slow piece of crap.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff's furious key-hammering produced this:
> Ugh...IE under OS X is a slow piece of crap.
Agreed. Sadly, though, the Windows version still isn't as good as the Mac OS
release when it comes to CSS...
Of course, when the IE:Mac for OS 9.2 behaves in a similar fashion to running
IE:Win under Win9X, it's definitely something to avoid (I had two total crashes
under OS 9.2 last night because of IE:Mac). At least IE for OS X is a bit more
stable.
--
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
