问题标签 [indexed]

有没有办法知道何时实际使用 uitableview 上的索引？我在 Apple 文档中找不到任何方法，但我想知道其他人是否知道任何事情。我基本上想在我的表视图中制作一个动画，该动画会根据在索引中选择的部分而变化，我不知道如何在不访问表视图索引的情况下执行此操作。

任何帮助是极大的赞赏。

谢谢。

I'm trying to get a clear idea of when I should be using indexed arrays of OpenGL vertices, drawn with gl[Multi]DrawElements and the like, versus when I should simply use contiguous arrays of vertices, drawn with gl[Multi]DrawArrays.

(Update: The consensus in the replies I got is that one should always be using indexed vertices.)

I have gone back and forth on this issue several times, so I'm going to outline my current understanding, in the hopes someone can either tell me I'm now finally more or less correct, or else point out where my remaining misunderstandings are. Specifically, I have three conclusions, in bold. Please correct them if they are wrong.

One simple case is if my geometry consists of meshes to form curved surfaces. In this case, the vertices in the middle of the mesh will have identical attributes (position, normal, color, texture coord, etc) for every triangle which uses the vertex.

This leads me to conclude that:

1. For geometry with few seams, indexed arrays are a big win.

Follow rule 1 always, except:

For geometry that is very 'blocky', in which every edge represents a seam, the benefit of indexed arrays is less obvious. To take a simple cube as an example, although each vertex is used in three different faces, we can't share vertices between them, because for a single vertex, the surface normals (and possible other things, like color and texture co-ord) will differ on each face. Hence we need to explicitly introduce redundant vertex positions into our array, so that the same position can be used several times with different normals, etc. This means that indexed arrays are of less use.

e.g. When rendering a single face of a cube:

(this can be considered in isolation, because the seams between this face and all adjacent faces mean than none of these vertices can be shared between faces)

if rendering using GL_TRIANGLE_FAN (or _STRIP), then each face of the cube can be rendered thus:

Adding indices does not allow us to simplify this.

From this I conclude that:

2. When rendering geometry which is all seams or mostly seams, when using GL_TRIANGLE_STRIP or _FAN, then I should never use indexed arrays, and should instead always use gl[Multi]DrawArrays.

(Update: Replies indicate that this conclusion is wrong. Even though indices don't allow us to reduce the size of the arrays here, they should still be used because of other performance benefits, as discussed in the comments)

The only exception to rule 2 is:

When using GL_TRIANGLES (instead of strips or fans), then half of the vertices can still be re-used twice, with identical normals and colors, etc, because each cube face is rendered as two separate triangles. Again, for the same single cube face:

Without indices, using GL_TRIANGLES, the arrays would be something like:

Since a vertex and a normal are often 3 floats each, and a color is often 3 bytes, that gives, for each cube face, about:

(I understand the number of bytes might change if different types are used, the exact figures are just for illustration.)

With indices, we can simplify this a little, giving:

See how in the latter case, vertices 0 and 2 are used twice, but only represented once in each of the verts, normals and colors arrays. This sounds like a small win for using indices, even in the extreme case of every single geometry edge being a seam.

This leads me to conclude that:

3. When using GL_TRIANGLES, one should always use indexed arrays, even for geometry which is all seams.

Please correct my conclusions in bold if they are wrong.

我正在尝试从数据库中获取数据并按排序顺序显示所有值，这些值从 AZ 分组到各个部分，并且我的 UITableView 也被索引。在这种情况下，索引是 AZ。发生的奇怪事情是，当我将数据库中的所有值放到表中时，我看到“B”部分下的值具有“A”部分中的一些值，如果我点击任何索引，例如如果我点击索引'D' 并回到字母 'B' 部分，以前以 A 开头的值现在替换为 D。

这只发生在特别是“B”部分的值上。其他部分中的所有值均正确显示。抱歉，如果问题不清楚。这是我认为可以描述我的问题的最佳方式。

拜托我需要你的帮忙。完成这项任务非常紧迫，我不明白为什么会这样。

In a Section Indexed UITableView how do you make the title of the section chosen (by pressing the Section Index) align _not_ at the very top of the screen (under the navigation controller) but rather flush after the Navigation Bar Header at the top?

like this:

---

[button] Navigation Bar Header at top of screen [other button]

---

X (section letter)

---

items within section....

To be clear, the problem I am having is that when a section index is pressed on the right, the table scrolls that section to the very top of the screen, hidden underneath the navigation bar. I want that section header precisely after the navigation header touching the Navigation Bar bottom border with the top of the Section Letter row - as it is for example, when the table first appears.

如果你能找到一个基于姓氏的索引表视图的教程，比如“联系人”应用程序，那就太好了。我到处搜索，但找不到姓氏。

我不知道 GDI+ 是否支持将位图保存为 16 位灰度索引 png，但如果支持，我似乎无法做到。这可能吗？如果没有，是否有可以使用的开源库？

我有一个问题，我需要创建二维表，该表将由字符串索引，例如：

或锯齿状：

如何声明可以处理此问题的 Collection 或数组？我找到了解决方案，但我不确定它是否是最好的。

但是当我想创建一个新值时，我需要初始化新字典，所以为什么我认为该解决方案不是最正确的：

那么如何以最好的方式创建由字符串索引的二维数组（也许创建可以处理这个的新类）？

这是一张图片： 这张图片是一个简单的从黑色到透明的渐变，保存在完整的 RGBA PNG 中。

这是相同的图像，由 GIMP 转换为 indexed-alpha PNG（Photoshop 产生相同的结果） 正如您所见，渐变现在是半不透明、半透明的。

这又是同一张图片，只是这次它被我编写的 PHP 脚本转换为 indexed-alpha PNG：

所以我的问题是：为什么 GIMP 和 Photoshop 无法支持索引图像的部分透明度，而 PHP 脚本清楚地表明可以毫无问题地创建这样的图像？
调色板包含 alpha 信息的图像有什么“错误”吗？
一个更与编程相关的问题：最后一张图像中的这种透明度在 Internet Explorer 6 中是否有效？

我们通过这样的 sql 创建了一个索引视图：

同样在创建视图之后，我们在 Table1_ID 列上设置了聚集唯一索引。
所以 View 由两列组成：

我们有两个问题：

1. 如果我们使用Count(1)orCount_BIG(1)代替Count_BIG(*)，SQL 不允许我们在 Table1_ID 上设置索引
2. 我们如何控制第二列 ( Table2TotalCount) 的类型 - SQL 为该列提供一个long 可空类型。但是我们想将此列设置为int 不可为空的类型。创建视图后，我们找不到任何更改列类型的方法。我们用于创建视图的 t-sql 也总是将 int 值返回给Table2TotalCount。

Table1_ID我用这样的 T-SQL创建了索引视图（在 上的聚集唯一索引）视图：

同样在创建视图之后，我们在 Table1_ID 列上设置了聚集唯一索引。
所以 View 由两列组成：

用于创建 View 的 T-Sql 很重​​，因为 Table2 中有数百万行的 group by。

但是当我对像这样的视图运行查询时

- 它执行速度快，没​​有服务器开销。

同样在 t-sql 中，用于在Table2列的 where 子句中创建视图的许多条件。如果我将 Table2_DeletedMark 更改为 1 并运行查询

再次 - 我会得到正确的结果。（Table2TotalCount减少 1）。

所以我们的问题是：
1.为什么我们使用Indexed View时查询执行时间减少了这么多（与不使用视图相比（即使我们DBCC DROPCLEANBUFFERS()在执行查询之前运行到VIEW））
2.更改后

查看立即重新计算，我们得到正确的结果，但背后的过程是什么？我们无法想象每次我们更改 t-sql 视图生成中包含的 10+ 列的任何值时，sql 都会根据生成的视图执行 t-sql，因为它太重了。
我们知道运行一个简单的查询来重新计算值就足够了，这取决于我们更改的列值。
但是sql怎么理解呢？