It didn't really make sense to me to think the Sprite was broken, since it can be fed a 0,0,0,0 from other sources (like a CI Kernel), and works correctly.
I guess from briefly skimming your description and doing some tests, I figured it was /possible/ that the sprite was trying to do something in the name of performance by detecting a completely transparent image, and handling it incorrectly. This kind of mistake isn't unheard of, so I was keeping my options open :)
It's slightly unnerving to see bugs get deferred as being CI bugs, or some other department's bug, etc., and then I have to go on the CI list, or file it as a CI bug, or the driver department or whatever.
there's a fine line between "deferred" and "clarified" -- Being a developer myself, I know how valuable it is to have bugs clarified into the ground, as it saves me time trying to figure out what's going on. Also, the QC team might have absolutely no access to CI code -- as such, having them "front" the bug for you is not time efficient when it's clear where the problem lies (in this case it's not quite clear, as CI has quirky behaviour, but QC also has broken image handling for zero-size images, and both of those factors are at play -- I'm leaning more on the QC-bug side on this one, personally).
I understand that line of thought, but I would humbly say that it is incorrect. If I'm using QC, and this happens, it's a QC bug, and the QC dept. needs to handle this, or tell the Core Image dept., or whoever it is that needs to fix the bug. It's a QC bug, because QC uses CI. If it didn't use CI, then it wouldn't be a QC bug, because I would never see the bug to begin with. They should get up, and go walk over to the Core Image office, or whatever it is, instead of deferring it back on the user, or waiting for people on-list to figure it out for them.
Apple never did any deferring on this -- I brought up the possibility of the problem being a CI bug, but I've not ever witnessed any apple engineers saying "oh, that's actually a bug elsewhere!" (to defer -- they have done that to clarify, but that's different), and I've filed a ton of "QC" bugs that actually live in other frameworks. Also, by extension all bugs (with the exception of those experienced by Windows QT developers) are simply "Mac OS X" bugs, since we're using Mac OS X when it happens -- Where's the line? is it at the app level? the OS level? the framework level? my latter ridiculous example was OS level (everything's an OS X bug), my clarification on this issue was more framework level, and you're aiming for app-level. Any of those choices (or dozens of others) are arbitrary :)
I know that comes off as matter of fact, but I don't mean it to. I'm just used to a mindset of people taking ownership of a problem from cradle to grave. For example, If I called Apple up, and got "Joe Shmo" on the phone, I would expect them to go report this to whoever needs to know how to fix it, even if their job was totally unrelated. In this same way, I don't have an expectation of having to ask about this on the Core Image list, to have to isolate it to being CI, or write it up as a CI bug. I will most definitely write this up as a QC bug, since it happens in QC.
Joe Shmo might not /know/ who to contact regarding the bug. A bug exposed in QC can come from anywhere: WebKit, CoreImage, CoreVideo, QuickTime (haha), AppKit, CoreAudio, QC the application, QC the framework, Quartz, or any of a number of other minor frameworks used in QC. The sheer number of technologies involved under the hood in QC is staggering, and sometimes stuff filed as bugs against QC are actually in other frameworks. While these get sorted out eventually, it wastes the QC team's time trying to isolate the issue internally enough to hand it off to the respective department. I am in no way suggesting you get on the CI list, or file the bug differently. However, I would be dishonest to say that clarifying details will harm or hinder the bug's resolution -- saving some redundant engineer 15 minutes in bug hunting gives them 15 minutes to address other bugs, or add new features, or fix documentation, or whatever.
If someone in the Core Image department has to actually fix it instead of someone who works on QC, this should be transparent to me (pun intended).
I agree it should be transparent. I'm also not suggesting you refile the bug or do anything in particular (well, maybe add some notes to the bottom, but that's it). I'm simply noting stuff so any CI devs on the list, or any QC engineers, or anyone who has a chance at finding it can track it down more quickly. From experience, there's nothing more useless than someone telling us "There's a bug in a kineme patch!" because that means there's a bug in some unspecified subset of over a quarter million lines of code -- nice, but unhelpful without many more details. More details help refine which portion of those lines, savings lots of time/testing. I don't think you annotating the bug to clarify how to expose the bug using raw CI code will hinder Apple engineering in any way, and with any luck it might even help those assigned to fix the problem to actually know where to start looking. That's my sole reason for trying to isolate the issue and minimize the amount of extraneous stuff involved. :)
And in the interval where it's not fixed, other users can see what factors are at play so they can avoid it or find a workaround or at least know that it's a known issue. :)
-- [ christopher wright ] [email protected] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
