程序员吐血而死系列:VC+图形处理=聊斋志异?

首先我们看看剪贴板.翻遍msdn愣是没找着一个例程.最后在codeproject上看到一段示例;
  if (FALSE==win->OpenClipboard ())return 0;
  HANDLE hDib=(HANDLE)::GetClipboardData(CF_DIB);
  HBITMAP retBmp,oldBmp;
  LPBITMAPINFOHEADER lpBI;
  lpBI = (LPBITMAPINFOHEADER)::GlobalLock((HGLOBAL)hDib);
  if(lpBI)
  {
   CDC memDC;
   memDC.Attach (CreateCompatibleDC(GetDC (NULL)));
   retBmp=CreateCompatibleBitmap(GetDC (NULL),
    lpBI->biWidth ,abs(lpBI->biHeight) );
   oldBmp=(HBITMAP)::SelectObject (memDC.GetSafeHdc (),retBmp);

   ::StretchDIBits(memDC.GetSafeHdc (),
    0, 0, lpBI->biWidth ,abs(lpBI->biHeight),
    0, 0, lpBI->biWidth ,abs(lpBI->biHeight),
    lpBI+1,(BITMAPINFO*)lpBI,
    DIB_RGB_COLORS, SRCCOPY);

   ::SelectObject (memDC.GetSafeHdc (),oldBmp);
   GlobalUnlock(GLOBALHANDLE(lpBI));
   CloseClipboard();
  }
  else return NULL;
 
  CloseClipboard();
  return retBmp;
还行，嗯?......用了一段日子发现不对:图象好象偏移了一些.狂郁闷中调试,结果发现,原来是因为16位及以上的DIB位图有三个DWORD掩码lpBI+1应改为((char*)(lpBI+1))+12;这还没考虑索引模式下的DIB............ 太麻烦..........查看GetClipbordData似乎有CF_BITMAP可用...也许M$会帮我们直接转成HBITMAP? 可是试过以后你就会发现,这只不过是M$耽误其它公司开发速度的又一手段罢了.

不只这些.在csdn中,我还发表了"为什么在opengl下纹理贴图失败","关于画椭圆的问题:线宽增加回变形","请教:如何解决MDI中文档切换的问题".至少有两个是因为M$.
比方说线宽增加会变形,在非填充模式下画椭圆,线宽太大时椭圆的内部可能变方的圆的菱的...连GDI+也如此.难怪mspaint只有那么一点线宽,难怪coreldraw最大线宽只用24.....原来是API太烂;
至于MDI中文档切换会闪现一个frame,看来连VC编辑器本身都有
这个毛病.就别提M$可以解决了.曾经拦截了一下WM_ACTIVATE消息,看看能不能让那deACTIVATE的frame不画.结果是白费心机:原来,在NT系列中,为了给用户图形性能还可以的感觉,画frame的标题栏之类是操作系统代劳,想让它不画都不行....干脆变成X window得了.(2004.2.9修订:拦截WM_NCPAINT消息即可解决问题.感谢zhi_liu6)

.........考虑良久,觉得比尔实在是个天才------孜孜不倦地把垃圾推销给世人,甚至为垃圾技术建立标准.象这种天才只涉足计算机领域实在太可惜了,回收站,废品收购处都有他这种人,肯定可以为环境保护出一份大力.............

言归正转:鬼异的事还刚开始.

在矢量绘图中,擦图操作通常由一系列的小线段开始.于是我用STL的vector存储点序列.在用户连续擦了几分钟后系统崩溃了:没有内存.只不过是几M大小就会失败了.只好用list,一开始在while循环中迭代list的节点,你猜如何?要好几秒钟!改成for循环就没这问题了.又改回while循环,也没问题了!晕~~~

还有opengl问题.根据M$的神话传说,window 下的opengl绘图是支持DIB位图绘制的.就是说你用CreateDIBSection建立一个DIB,就可以使用opengl绘图了,这样你可以很方便的支持位图了:比方说你可以建立一个2048*2048的大位图.在上面进行操作,
而且可以用GDI因为你不需要window的双缓冲.保存为位图就太方便了:把CreateDIBSection返回的数据指针指向的数据存储即可.高兴啊.....等等,怎么这么慢!看看opengl版本:1.1;厂商:M$也!不会吧,怎么window的opengl是1.3和ATI呢!疯狂调节各种参数...最后发现:神话就是神话.

opengl纹理贴图为何失败?我把这个问题提交了csdn,数字图像网,www.opengl.org,www.gamedev.net,中国游戏开发者......
愣是没人答出来.最后发现了:原来,在glTexImage2D调用后,你如果不调用glTexParameteri设置GL_TEXTURE_MAG_FILTER和
GL_TEXTURE_MIN_FILTER,那就可能什么也贴不上.不会报任何错!老大你就算默认为GL_NEAREST也好啊!怎么来个干脆不画呢!!!

各位同学,如果你们还没吐血的话,我还有一个秘方;准保你们看得舒心,死得开心:
随便一个hello world级别的代码
#include "stdafx.h"
#include <windows.h>
#include <gl/gl.h>
struct glBitmap
{
static glBitmap* FromHBITMAP(HBITMAP hbmp);
};

glBitmap *glBitmap::FromHBITMAP
(HBITMAP hbmp)
{
 return 0;
}
int main()
{

}

编译不过是不是?把#include <gl/gl.h>去掉看看:)

原文转自：http://www.ltesting.net