[ Yourself <user@shredder.(none)> ]You might want to fix your Git config.
Thanks, I caught that...too late I switched to a new nightly and made the commit before copying over the config... should be fixed now, will see on the next commit
Most of your critiques are spacing and the like. I change the code so quickly I rarely think about how it looks until I know it is gonna stick around. Still, I will address the style violations in my next commit. Most were caused by deleting old code from the previous version, or copy & pasting... too much in a rush to get things compiled... and I like things to stick out until they're done...bad habit in public code!
+ * Copyright 2001-2009, Haiku, Inc.That old already?
LOL... oops! Not even sure why those blocks would even be there yet...they don't belong (may have been a remnant from testing an auto-insertion tool... I like automating mundane tasks... even if I could have finished that task manually much sooner than writing code to do it for me...).
+{ + fLock.Lock(); + + if (fBufferFillSrc != NULL) + free(fBufferFillSrc); + if (fBuffer != NULL) + free(fBuffer);Don't test for NULL when calling free() or delete.
I actually had crashes when not checking, but I think I discovered the problem to be elsewhere and was merely crashing once it got to free due to an overrun...
+ if (fBufferFillSrc == NULL){ + fBufferFillSrc = (uint32*)malloc(bpr); + for (uint32 i = 0; i < bpr/4; ++i) + fBufferFillSrc[i] = fBufferFillPattern;This is the app_server *ALWAYS* test if an allocation succeeds or not.
Wow, nice catch! Surprised I missed that... must have been rushing along...
+WindowBuffer::SetBufferFillPattern(uint32 pattern) +{ BAutolock _(fLock);Don't do that.
Do what, exactly? The lock? Or putting the BAutolock _(fLock); on the same line as {?
+ int32 srcWidth = fWidth, + srcLen = srcWidth*bpp, + destWidth = width, + destLen = destWidth*bpp, + srcHeight = fHeight, + xDelta = width - fWidth, + xDeltaLen = xDelta * bpp, + yDelta = height - fHeight, + xShrinkDelta= 0;Use the type in each line. Don't indent this way: Only use a single space after the variable name.
Ugh, I much detest given the type to each line. Not sure why... seems redundant when a comma serves the purpose so well. Oh well, I'll play by your rules and fix it...
+ WindowBuffer(Window* window); + virtual ~WindowBuffer(); + + size_t MemoryUsage(); + + // resizes the WINDOWWhy upper case?
I use caps when I'd prefer to bold something. I tend to go comment-heavy while writing code, then I go back and destroy most of them. The comments are most often meant for me - my memory doesn't work very well
Anyway, I very much appreciate you looking at it... I'll clean up the style violations and address the other flaws you mentioned as well.
--The loon
