Kenneth Russell wrote:
How exactly does the implementation know which is the "current" context? Aren't all the functions method calls on a context object? In which case the application can interleave calls without the implementation being any the wiser, unless it instruments the calls.On Fri, Feb 5, 2010 at 12:17 AM, Mark Callow <email@example.com> wrote:It can be implemented more simply: if the last context against which a call was made is not equal to the current context, call the wait() primitive against this context -- or, depending on how it's implemented, against the previous context or both contexts. It isn't really necessary to instrument all of the drawing commands. The assumption should be that many calls (not just drawing calls) are made sequentially against any given context.
I do not understand why incorrect rendering for a buggy program is such a stumbling block. Why is failure to put in a required waitContext call any different than any other omission that prevents the program producing correct results?But my main concern is that the vast majority of developers will simply not realize that by adding that bit of fancy 2D text drawn they are killing their performance. The presence of an explicit waitContext() gives them a clear warning that switching contexts is expensive.The incorrect rendering behavior for not calling waitContext() is in my opinion too big a stumbling block. I think we should advise developers to stick to one context for best performance, but produce correct rendering results if they interleave calls to multiple contexts.
begin:vcard fn:Mark Callow n:Callow;Mark org:HI Corporation;Graphics Lab, Research & Development adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan email;internet:firstname.lastname@example.org title:Chief Architect tel;work:+81 3 3710 9367 x228 tel;fax:+81 3 5773 8660 x-mozilla-html:TRUE url:http://www.hicorp.co.jp, http://www.mascotcapsule.com version:2.1 end:vcard