Hi, > Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach > <f.heckenb...@fh-soft.de> escreveu: > > > > > I think that we should revert this change for the time being, though, > > > because if it was working in this way for about a decade and the > > > programs using FTGL worked "fine" despite having some bug there, > > > > Sorry, they did *NOT* all work fine, see my bug report. > > I agree with that, that's why I said "fine" with quotes included. I > thought about adding "(for some value of 'fine')", but stopped short > :-) > > However, from how I understand it, having completely blank rectangles > in the position of letters (which happens with critterding and > darkradiant for example) is worse than what happened before in your > original report -- it would perhaps be the worst case scenario of what > could happen before.
For some value of "worse". For me, it could as well draw unicorn rainbows; shipping my software with wrong colour effects is simply inacceptable. > Is there a way to easily determine when the applications are buggy by > searching the code? Maybe we can find an upper limit to the > problematic applications, or provide patches, if feasible. The upper limit is of course, all applications that use FTGL and render letter (which is probably the same as all applications that use FTGL at all). As things can be resolved differently in the caller (which is basically the purpose of the change), I don't think there's an easy way to check it automatically. > > - A slightly more complex solution would be a flag to select the > > behaviour. Of course, it would need to be a runtime flag. It may > > default to the old behaviour, but that should be deprecated (and > > print a strong depreciation message -- unfortunately that would > > have to be at runtime too AFAICS, or is there a way to warn at > > compile time when a program, say, does *not* reference a > > particular function?). > > I am not familiar with OpenGL stuff. Is there a way to detect if a > "Blending Mode" is provided at runtime, when the function is called, > and if not, provide a default one like the one before, and possibly > emitting errors for it to raise attention (both compile time and > runtime)? All I know is that OpenGL state is a complex beast, and even if there's a way to query relevant info, it wouldn't be recommended as it adds a round-trip and thus latency. OpenGL is supposed to be used unidirectionally as much as possible. And it would smell like a kludge anyway. > Another option would be to have an extra argument in the function, say: > > inline FTPoint FTBitmapFontImpl::RenderI(const T* string, > const int len, > FTPoint position, > FTPoint spacing, > int renderMode, > bool disableBlend = false); Apart from the (slight) runtime overhead, this seems to make it hard to change the default to the new behaviour later. > Or perhaps a new function to enable/disable globally if the library is > initialised, or an env flag, or similar. That's more like what I had in mind. But if the default is the old behaviour if this function is not called, and we want to deprecate this, we can only warn at runtime (unless, as I said, there's a way to find out at compile time that the function is not referenced -- sure, one could reference the function without calling it, but that would be malicious, not worth worrying about). > And I think that the default would have to be the old behaviour, yes, > because after many years behaving in that way the applications must > have learned to adapt or cope, and no one knows that they have to use > a different flag or invoke the method with an extra parameter. For some value of "the applications". You're talking about Debian only again, of course, but there are other applications that have come to expect the new behaviour (obviously at least mine and the patch author's ones, possibly more -- there's a number of forks of FTGL on github, probably by people who use(d) it). > I realise that maybe this is not what you like because applications > will ever remain buggy, but reallistically, The same applies vice-versa for applications that rely on the new behaviour if we make the old one the default. The problem is we have different semantics already (and for almost 10 years apparently). Perhaps the only sane way out is to add *two* new versions of each rendering function, one with each behaviour, and deprecate the old ones entirely. This will require changes in all applications (if only to select the correct one of the two which should be easy if ones knows which branch of the library they used before), but at least it will be clear at compile time. > some might even be > abandoned upstream, so they could remain unusable forever. If they're abandoned, what's their expected lifetime anyway? I've seen enough packages disappear from Debian, so much that I actually refrain from reporting bugs to fragile applications (in the sense of dubious maintenance) for fear that the resolution will be to simply drop them. Cheers, Frank
